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
