From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B2ABFA00BE; Wed, 27 May 2020 22:35:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2EFA21DA5F; Wed, 27 May 2020 22:35:19 +0200 (CEST) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 89E1A1DA5D for ; Wed, 27 May 2020 22:35:18 +0200 (CEST) Received: from 2606-a000-111b-4634-0000-0000-0000-1bf2.inf6.spectrum.com ([2606:a000:111b:4634::1bf2] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1je2lU-0006Kv-5X; Wed, 27 May 2020 16:35:08 -0400 Date: Wed, 27 May 2020 16:35:03 -0400 From: Neil Horman To: Thomas Monjalon Cc: Fady Bader , dev@dpdk.org, Harini Ramakrishnan , Omar Cardona , Pallavi Kadam , Ranjit Menon , dmitry.kozliuk@gmail.com, mdr@ashroe.eu Message-ID: <20200527203503.GA1603965@hmswarspite.think-freely.org> References: <1906091.XQj0qEek43@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1906091.XQj0qEek43@thomas> X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] ABI versioning in Windows X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, May 27, 2020 at 02:50:07PM +0200, Thomas Monjalon wrote: > +Cc more people > > 27/05/2020 12:41, Fady Bader: > > What should we do with the ABI versioning in Windows ? > > I think there are 2 questions here: > > 1/ Do we want to maintain ABI compatibility on Windows like we do for Linux and FreeBSD? > The decision must be clearly documented. > My first notion, without any greater thought is "why wouldn't we". ABI stability is OS agnostic. If a symbol is considered stable, theres no reason that I can think of that it wouldn't be stable for each OS. > 2/ How do we implement the macros in rte_function_versioning.h for Windows? > Something needs to be done, otherwise we cannot compile libraries having some function versioning. > Can you elaborate on what exactly the issue is here? I presume by your comment above that visual studio either doesn't support symbol level versioning or doesn't support versioning at all? If thats the case, and there is a commitment to make dpdk buildable on windows, I suppose the only choice is to make a ifdef WINDOWS section of the rte_function_versioning.h file, and effectively turn all the macros into no-ops. The BIND_DEFAULT_SYMBOL macro looks like it could still work, as MSVC has an alias linker command thats implementable via __pragma, but thats probably all we can do, unless there is some more robust versioning support that I can't find. Note we will also likely need to agument the makefiles/meson files so that the link stage doesn't pass the version script to the linker Neil > >