From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6487841EA1; Wed, 15 Mar 2023 16:45:33 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4A6BF40A7A; Wed, 15 Mar 2023 16:45:33 +0100 (CET) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id CE52B40141 for ; Wed, 15 Mar 2023 16:45:31 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7450310588 for ; Wed, 15 Mar 2023 16:45:31 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 72F71FEF7; Wed, 15 Mar 2023 16:45:31 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED, AWL, NICE_REPLY_A autolearn=disabled version=3.4.6 X-Spam-Score: -1.4 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id B4117FF69; Wed, 15 Mar 2023 16:45:29 +0100 (CET) Message-ID: Date: Wed, 15 Mar 2023 16:45:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Subject: Re: PIE static library builds To: Bruce Richardson Cc: "dev@dpdk.org" , =?UTF-8?Q?Mattias_R=c3=b6nnblom?= References: <075645fc-f40d-82c6-52d5-ce8b23f3cdeb@lysator.liu.se> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 2023-03-15 15:18, Bruce Richardson wrote: > On Tue, Mar 14, 2023 at 06:31:41PM +0000, Bruce Richardson wrote: >> On Tue, Mar 14, 2023 at 07:04:19PM +0100, Mattias Rönnblom wrote: >>> On 2023-03-14 17:29, Bruce Richardson wrote: >>>> On Tue, Mar 14, 2023 at 05:22:02PM +0100, Mattias Rönnblom wrote: >>>>> Hi. >>>>> >>>>> Is the "b_staticpic" meson build option supposed to work with DPDK? >>>>> >>>>> Setting it to "false" (default is "true") causes link failures on >>>>> Ubuntu 22.04, with GCC 9 and 11, on v23.03rc1 and v22.11: >>>>> >>>>> /usr/bin/ld: lib/librte_eal.a.p/eal_common_eal_common_errno.c.o: >>>>> relocation R_X86_64_TPOFF32 against `per_lcore_retval.1' can not be >>>>> used when making a shared object; recompile with -fPIC /usr/bin/ld: >>>>> failed to set dynamic section sizes: bad value collect2: error: ld >>>>> returned 1 exit status >>>>> >>>>> Does something per-lcore/TLS-related require PIC builds, even for >>>>> static libraries? >>>>> >>>> I don't think that is the issue. The "issue" is that DPDK always does >>>> both static and shared builds from the same object files, so without >>>> -fPIC the shared library parts of the build fails. To support not >>>> using staticpic, we'd have to disable building the .so's in those >>>> cases, or each C file built twice. >>>> >>> >>> With "default_library" set to "static", shouldn't the shared objects be >>> skipped? I can see now, they are not. >>> >> >> Yep, they aren't skipped. The reasons for this are partially historical, >> and partially due to meson limitations around linking (which may now also >> be historical). >> >> When we originally switched over to meson, IIRC there was no >> "both_libraries" option, but we still had a situation where: * we wanted >> to use and link staticly by default * we had *lots* of issues with >> patches breaking builds as submitters had forgotten about shared libs >> e.g. updating the version map Therefore, from the earliest versions of >> the meson builds we had DPDK always build both libraries - using our own >> logic. [This did have the desired effect of mostly eliminating version >> map issues once everyone whiched over, which was nice!] >> Symbols missing in version.map will be caught by the build bots, correct? Provided they build shared object builds, as well as the default. This feedback is received only after the patches have been submitted, but usually there are still several revisions of a patch set anyways. >> As things moved on, meson did add support for "both_libraries", and I did >> investigate using it in DPDK to have proper static-only, shared-only and >> both-library builds. Unfortunately, the assumption in meson was that if >> both libraries were built, the apps would link against the shared >> versions. Therefore, any change to use "both_library" support in DPDK >> would unfortunately lead to a change in default behaviour as our builds >> would all be shared, rather than static. [I have not checked recently to >> see if this can be overcome.] >> >> This is why things as where they are right now. :-) >> > For the sake of completeness: one other complication I forgot to mention - > using function versioning. When we have a library containing versioned > functions the build needs to be performed slightly differently depending on > whether we are building it as a static or a shared library. This is because > the verisoning macro need to expand slightly differently depending on the > build type. This prevents us from using "both_libraries" in these cases. > [And why, right now, we need to explicitly tag any libs with versioned > functions, so we can compile all the source files twice, with different > flags]. > I'm not sure I follow here. Are separate object files built for static and shared libraries, or not? Here it sounds like they have to be built with different flags, but earlier I thought you said static and dynamic libraries were assembled from the same object files. If you set "b_staticpic=false" the build is still partially successful, and you can build separate applications (e.g., dpdk-test). I ran some performance tests, and it seems like there may be some performance to gain from building with -fPIE.