From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) by dpdk.org (Postfix) with ESMTP id D199AB463 for ; Fri, 20 May 2016 18:43:57 +0200 (CEST) Received: by mail-qk0-f172.google.com with SMTP id n63so69760424qkf.0 for ; Fri, 20 May 2016 09:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p8rTQ2+kiRL5rvQxH5wRW3aHZcmbqUzKmH3WEFrCxuE=; b=EXLldnRxhZWX5jZH5rh2akGgZ4/dT5eijH/Pg0a9qRP1vdsc8PWJYQkbegn2fbOJwg K1qu6qclxgDxUvnM+73cB9VhzEe5xGMwEUFBcH8cXknCXVpAcNHZQf7Ml7m2CvQ9rUZr V7Pcl0cEy3V4q6ps0Ia25KXbb6D6HNzUt2dJG8waOP8B3TBHRN2Tpp4VCHITmE65tqA0 1/KzY3gWTsLVrz3eDPQyvI4gOgNEN3TMXKOGr4ggJ1pz3hvfK5eDrm+AEvdX6f978vGC wUnbAkm+baGjDaWqJ4rs4rm0djxpk8NxP2oI5j5YTwYWxzEXf6lCOTw96PRzMVq90USe abTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p8rTQ2+kiRL5rvQxH5wRW3aHZcmbqUzKmH3WEFrCxuE=; b=GmCMFv9LbbtiqcBCW7NIP4+aaJ2StS7CFW15iQ5cTinbT3B6Ot9TPyhi0X6/J9NLQ7 rCf5Xg6aoyY4YpJlnhkoSnVwPuxey4DO0wo0YOkCHdLqmh3w0IjwJPPqqSrmkM1IVUw4 YpOKiu3m5olRIXkiCK9vmk6ztCoNtJ0nTK0MubVzgsUEkc/NMeWW+fjI2nwMi3shp9Bi ZOe7YaKfG+OrALMG25Hl7tQp8PazOK1Rfu4Gjqrhc9/aTOAerePfj71AtDa95waIq8zX yeBZa8Nte2avE89vkNBdjZM+ab3U+mux9gCu+WFCYYLundT05MHTUHYliFUcyJ9A0cq7 XDDQ== X-Gm-Message-State: AOPr4FX4s2dOIDpYg6coHTTR2cSLvOPYzACkX1fvlHhfcjtV3NMB0gq2rp2ENfpTEHxjDOXHg8FK3Q4nLUHOJN7c X-Received: by 10.55.189.132 with SMTP id n126mr4518980qkf.117.1463762637107; Fri, 20 May 2016 09:43:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.97.3 with HTTP; Fri, 20 May 2016 09:43:37 -0700 (PDT) In-Reply-To: References: <2785570.uvvpCYCSoT@xps13> From: Christian Ehrhardt Date: Fri, 20 May 2016 18:43:37 +0200 Message-ID: To: Panu Matilainen Cc: Thomas Monjalon , dev Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] Underlinked libs and overlinked applications - an issue? 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: Fri, 20 May 2016 16:43:58 -0000 ok, - little baby steps first I'll submit a trivial patch in reply to this fixing the underlinking in all .so's, except librte_eal. - discussion on the remaining open issue second. For the remaining issue I think that needs a special understanding of linkers I still need to grasp. But since I failed to find a good explanation for the exact case we face here I put it in a generalized form on StackOverflow so eventually more than just us can benefit from the answer once/if we find an answer. So to all of you - if you are not scared of the latter pages of ld/gcc man pages :-) feel free to take a look at http://stackoverflow.com/questions/37351699/how-to-create-both-so-files-for-two-circular-depending-libraries For us, but not important for the question in general: liba = librte_eal, libb = librte_mempool (and ring, ivshmem, but once it is solved once it is solved) Time to stip for now, have a great Weekend Christian Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd On Fri, May 20, 2016 at 2:41 PM, Christian Ehrhardt < christian.ehrhardt@canonical.com> wrote: > On Fri, May 20, 2016 at 1:01 PM, Panu Matilainen > wrote: > >> On 05/19/2016 09:17 PM, Thomas Monjalon wrote: >> >>> 2016-05-19 17:38, Christian Ehrhardt: >>> >>>> Hi, >>>> I was working on the new 16.04 build system to adapt deb packaging to >>>> it. >>>> I remember somewhen back in the DPDK 2.2 and shared+combined library >>>> days I >>>> had some issues with over/underlinking - but it seems those are still >>>> existent or came back. >>>> >>> >>> I would say it has always been like that. >>> Thanks for raising the issue. >>> >>> After a build in almost default config (just disabled the kernel modules) >>>> and set RTE_MACHINE to default I find the following. >>>> >>>> #1 >>>> The libraries are all only linked against external things - even clearly >>>> using internal structures: >>>> ldd usr/lib/x86_64-linux-gnu/librte_lpm.so.2 >>>> linux-vdso.so.1 => (0x00007fff7e7a5000) >>>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f175d4dd000) >>>> /lib64/ld-linux-x86-64.so.2 (0x0000558d3afbf000) >>>> >>> >>> The DT_NEEDED entries are created only for external dependencies. >>> Probably we should create ones for internal dependencies based on the >>> variable DEPDIRS-y. >>> >> >> Yes, DT_NEEDED for internal dependencies are needed too, see eg recent >> commits c6417ce61f83 and 8180554d82b3. That was part of Sergios' build >> system improvement patch series last spring or so (but since then >> abandoned), I picked up the work and been doing it in smaller pieces. Phase >> 1 was the external dependencies, phase 2 is internal dependencies which I'm >> working on. Unfortunately health issues have stalled my work a lot recently >> :-/ > > > Since I work on 16.04 as released currently I almost missed those, but I > at least remember seeing the first on the list. > I had almost the same change - adopting yours since it is accepted. > Maybe I can provide a few more baby steps on that path - or at least a few > more pieces for discussion and review. > I hope you get well soon Panu! > > >> #2 >>>> The Application then seem to try to make up for that by realizing all >>>> that >>>> is missing. >>>> But looking at the app alone it seems overlinked by that - it is not >>>> using >>>> all of these on its own. >>>> ldd usr/bin/cmdline_test >>>> linux-vdso.so.1 => (0x00007ffeec9ea000) >>>> librte_distributor.so.1 => not found >>>> librte_reorder.so.1 => not found >>>> [...] >>>> librte_jobstats.so.1 => not found >>>> [...] >>>> And for example none of the librte_jobstats.so.1 symbols are used >>>> "directly" in there. >>>> >>> >>> Yes every libraries are put for every apps in rte.app.mk. >>> Probably that we could better use DEPDIRS-y for apps. >>> >>> >> Another trick from Sergios' original patch series is to utilize >> AS_NEEDED() in the linker script, so it ends up looking something like this >> for shared library config (static would remain as it is now): >> >> INPUT ( librte_eal librte_mempool librte_ring >> AS_NEEDED ( librte_acl librte_timer librte_vhost <...> ) >> ) >> >> ...and then use the linker script for linking the apps, which should >> simplify rte.app.mk considerably. Or so the theory goes. Anyway, the >> above requires DT_NEEDED for the internal libraries to be present first, >> but once all these pieces are in place, dynamically linked apps will only >> link to the libraries they actually need. >> > > Interesting approach, I wasn't even working on DPDK back then - that could > really simplify the mk there. > I was experimenting with just dropping the "no-as-needed" in > mk/exec-env/linuxapp/rte.vars.mk, but that seems to shoot too far - > haven't had the time to look deeper. > Interested if your approach could help. > > But the other part of it - getting the proper DT_NEEDED into the libs (I > also consider underlinking worse than overlinking) seems to be just missing > a bunch of -l - my last test build looked fine. > There is the underlinking issue of librte_eal left that Sergio mentioned > back in 6d25d90c, but it seems to be the next baby step to solve most else > of the underlinking. > I'll adapt it to git level and at least throw it out for discussion later > on. > >