From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 62A259AEA for ; Fri, 20 May 2016 13:01:12 +0200 (CEST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D35717F36F; Fri, 20 May 2016 11:01:11 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-6-156.ams2.redhat.com [10.36.6.156]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4KB1Abm012690; Fri, 20 May 2016 07:01:11 -0400 To: Thomas Monjalon , Christian Ehrhardt References: <2785570.uvvpCYCSoT@xps13> Cc: dev@dpdk.org From: Panu Matilainen Message-ID: Date: Fri, 20 May 2016 14:01:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <2785570.uvvpCYCSoT@xps13> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 20 May 2016 11:01:11 +0000 (UTC) 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 11:01:12 -0000 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 :-/ >> #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. - Panu - - Panu -