Re: PIE static library builds

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

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. :-)

/Bruce