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
