Re: PIE static library builds

[Bruce Richardson <bruce.richardson@intel.com>]

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!]
> 
> 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].

/Bruce