From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 37C00ADFA for ; Thu, 12 Feb 2015 16:52:40 +0100 (CET) Received: from [67.210.173.2] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YLw47-0000Ig-M6; Thu, 12 Feb 2015 10:52:34 -0500 Date: Thu, 12 Feb 2015 10:52:25 -0500 From: Neil Horman To: Panu Matilainen Message-ID: <20150212155225.GB4634@neilslaptop.think-freely.org> References: <20150129194539.GG1999@hmsreliant.think-freely.org> <91383E96CE459D47BCE92EFBF5CE73B004F453D7@IRSMSX108.ger.corp.intel.com> <20150130140507.GA2664@hmsreliant.think-freely.org> <91383E96CE459D47BCE92EFBF5CE73B004F45534@IRSMSX108.ger.corp.intel.com> <20150130181249.GC2664@hmsreliant.think-freely.org> <91383E96CE459D47BCE92EFBF5CE73B004F4AB9B@IRSMSX108.ger.corp.intel.com> <54DC70F3.4020902@redhat.com> <54DC7A87.1090208@intel.com> <20150212122354.GB8729@neilslaptop.think-freely.org> <54DCB3B6.1010204@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54DCB3B6.1010204@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 15:52:40 -0000 On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: > On 02/12/2015 02:23 PM, Neil Horman wrote: > >On Thu, Feb 12, 2015 at 10:03:51AM +0000, Gonzalez Monroy, Sergio wrote: > >>On 12/02/2015 09:22, Panu Matilainen wrote: > >>>On 02/11/2015 01:11 PM, Gonzalez Monroy, Sergio wrote: > >>>>>From: Neil Horman [mailto:nhorman@tuxdriver.com] > >>>>>Sent: Friday, January 30, 2015 6:13 PM > >>>>>To: Gonzalez Monroy, Sergio > >>>>>Cc: Thomas Monjalon; dev@dpdk.org > >>>>>Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > >>>>> > >>>>>On Fri, Jan 30, 2015 at 05:38:49PM +0000, Gonzalez Monroy, Sergio > >>>>>wrote: > >>>> > >>>>[snip] > >>>> > >>>>>> > >>>>>>So would it be reasonable to add DT_NEEDED entries to all DPDK > >>>>>>libraries > >>>>>but EAL? > >>>>>>If I understood what you were saying right, we could enforce the > >>>>>>'dependency' in the linker script with something like this: > >>>>>>$ cat librte_eal.so > >>>>>>INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such > >>>>>>linker script for librte_eal.so instead of the soft link once > >>>>>>versioning is in place. > >>>>>> > >>>>>Correct. > >>>>> > >>>>>>Things that would be missing versus the proposed patch: > >>>>>> - As I have mention in previous post, ldd info for EAL library > >>>>>>would not > >>>>>reflect > >>>>>> its dependency to other DPDK libs. > >>>>>librte_eal.so would no show those dependencies, as far as I know > >>>>>(though I > >>>>>haven't explicitly checked). The subordunate libraries included in > >>>>>the input > >>>>>line, may or may not show dependencies among themselves, depending on > >>>>>your build setup (and the use of --no-as-needed and -l when linking the > >>>>>individual .so libraries. > >>>>> > >>>>>> - I was enforcing resolving all references when building the > >>>>>>libraries (-z > >>>>>defs), so > >>>>>> we either remove it altogether or skip eal. > >>>>>I think thats correct, yes. > >>>>> > >>>>>> - All apps would show DT_NEEDED entries for a set of DPDK > >>>>>>libraries that > >>>>>> in most cases are required (eal, mempool, malloc, mbuf, ring VS > >>>>>>dpdk_core) > >>>>>> > >>>>>I think apps linked to libdpdk_core would have DT_NEEDED entries for > >>>>>libdpdk_core, not the subordonate libraries (though check me on that > >>>>>to be > >>>>>sure). > >>>>> > >>>>Just checked on this and they do link against the subordinate libraries, > >>>>although > >>>>It does not really matter as we are dropping the 'core' library approach > >>>>anyway. > >>>> > >>>>>>I think that the linker script approach is reasonable if we prefer to > >>>>>>go that way instead of creating a core library. > >>>>>> > >>>>>I think it would make sense from a build environment point of view, in > >>>>>that it > >>>>>allows library specific flags to be incorporated properly. I think > >>>>>the only > >>>>>downside is that the individual libraries still need to be carried > >>>>>around > >>>>>(though they can be ignored from an application build/run standpoint). > >>>>>You're question should probably be asked of people using COMBINED_LIBS > >>>>>currently to make sure that meets their needs, though I think it will. > >>>>> > >>>>>Neil > >>>>> > >>>>So I just realized that I was not having into account a possible > >>>>scenario, where > >>>>we have an app built with static dpdk libs then loading a dso with -d > >>>>option. > >>>> > >>>>In such case, because the pmd would have DT_NEEDED entries, dlopen will > >>>>fail. > >>>>So to enable such scenario we would need to build PMDs without DT_NEEDED > >>>>entries. > >>> > >>>Hmm, for that to be a problem you'd need to have the PMD built against > >>>shared dpdk libs and while the application is built against static dpdk > >>>libs. I dont think that's a supportable scenario in any case. > >>> > >>>Or is there some other scenario that I'm not seeing? > >>> > >>> - Panu - > >>> > >>I agree with you. I suppose it comes down to, do we want to support such > >>scenario? > >> > >> From what I can see, it seems that we do currently support such scenario by > >>building dpdk apps against all static dpdk libs using --whole-archive (all > >>libs and not only PMDs). > >>http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 > >> > >>Am I misunderstanding this? > >> > >Shoot, you're right, I missed the static build aspect to this. Yes, if we do the following: > > > >1) Build the DPDK as a static library > >2) Link an application against (1) > >3) Use the dlopen mechanism to load a PMD built as a DSO > > > >Then the DT_NEEDED entries in the DSO will go unsatisfied, because the shared > >objects on which it (the PMD) depends will not exist in the file system. > > I think its even more twisty: > > 1) Build the DPDK as a static library > 2) Link an application against (1) > 3) Do another build of DPDK as a shared library > 4) In app 2), use the dlopen mechanism to load a PMD built as a part of or > against 3) > > Somehow I doubt this would work very well. > Ideally it should, presuming the ABI is preserved between (1) and (3), though I agree, up until recently, that was an assumption that was unreliable. > > > >I think the problem is a little bit orthogonal to the libdpdk_core problem you > >were initially addressing. That is to say, this problem of dlopen-ed PMD's > >exists regardless of weather you build the DPDK as part of a static or dynamic > >library. The problems just happen to intersect in their manipulation of the > >DT_NEEDED entries. > > > >Ok, so, given the above, I would say your approach is likely correct, just > >prevent DT_NEEDED entries from getting added to PMD's. Doing so will sidestep > >loading issue for libraries that may not exist in the filesystem, but thats ok, > >because by all rights, the symbols codified in those needed libraries should > >already be present in the running application (either made available by the > >application having statically linked them, or having the linker load them from > >the proper libraries at run time). > > My 5c is that I'd much rather see the common case (all static or all shared) > be simple and reliable, which in case of DSOs includes no lying (whether by > omission or otherwise) about DT_NEEDED, ever. That way the issue is dealt > once where it belongs. If somebody wants to go down the rabbit hole of mixed > shared + static linkage, let them dig the hole by themselves :) > This is a fair point. Can DT_NEEDED sections be stripped via tools like objcopy after the build is complete? If so, end users can hack this corner case to work as needed. Neil > - Panu - > > >Regards > >Neil > > > >>Regards, > >>Sergio > >> > >