Hi Folks: I've encountered a situation that is proving difficult to unravel and I'm hoping you folks might have some ideas.
We are building CURL from a source distribution-tarball (i.e., curl-8.14.1.tar.gz) on both RHEL 8.x and Amazon Linux 2023 based VMs. For our usage case, it is desired that the resulting "curl" binary use RPATH rules for resolving shared library locations, not RUNPATH rules. For example, we desire the results of a "readelf -d curl" command to include output like: 0x000000000000000f (RPATH) Library rpath: [/usr1/custom_location_1/lib:/usr1/custom_location_2/lib] and not output like: 0x000000000000001d (RUNPATH) Library runpath: [/usr1/custom_location_1/lib:/usr1/custom_location_2/lib] In the past with older versions of CURL and/or operating-systems, the inclusion of the linker flags like "-Wl,-rpath=/usr1/custom_location_1/lib" and "-Wl,-rpath=/usr1/custom_location_2/lib" would suffice to ensure the "curl" binary abided by RPATH rules. Recently though, and especially in Amazon Linux 2023 environments, we've noticed numerous executables/libraries that we build now using RUNPATH rules instead. As a result, in addition to the above-mentioned linker flags, we began to include the "-Wl,--disable-new-dtags" linker flag in LDFLAGS and that restored the executables/libraries to using RPATH rules except for the "curl" binary which continues to use RUNPATH rules. Investigation into the issue revealed that the "Makefile" generated as part of the autotool/automake configuration step of the build process defined a couple variables (LIBCURL_PC_LIBS_PRIVATE and LIBS to be specific) that included the linker flag "Wl,--enable-new-dtags", for example: LIBCURL_PC_LIBS_PRIVATE = -lnghttp2 -lidn2 -lgsasl -lpsl -lssl -lcrypto -lssl -lcrypto -Wl,--enable-new-dtags -Wl,-rpath -Wl,/usr1/custom_location_1/lib -L/usr1/custom_location_1/lib -lgssapi -lldap -llber -lz ... and ... LIBS = -lnghttp2 -lidn2 -lgsasl -lpsl -lssl -lcrypto -lssl -lcrypto -Wl,--enable-new-dtags -Wl,-rpath -Wl,/usr1/custom_location_1/lib -L/usr1/custom_location_1/heimdal/lib -lgssapi -lldap -llber -lz Upon seeing this, we began to understand why the "curl" binary was built to abide by RUNPATH rules; the "--enable-new-dtags" flag was dictating that result. But what we don't understand is what in CURL's autotool/automake configuration process could be causing the "--enable-new-dtags" value to be defined in the first place especially when the LDFLAGS value in play at the time CURL's configuration step was invoked appeared as: -L/usr1/custom_location_1/lib -Wl,-rpath=/usr1/custom_location_1/lib -L/usr1/custom_location_2/lib -Wl,-rpath=/usr1/custom_location_2/lib -Wl,--disable-new-dtags We thought perhaps a PKGCONF "*.pc" file for one or more of the ancillary packages the CURL build was to be built with during its build might have the "--enable-new-dtags" flag defined but a review of all "*.pc" files located in both system and custom "pkgconfig" directory locations came up empty. We eventually circumvented the issue by assigning the value "Wl,--disable-new-dtags" to the LIBS environment variable before performing the CURL build process' configuration step which resulted in a generated "Makefile" defining the LIBCURL_PC_LIBS_PRIVATE and LIBS variable values as: LIBCURL_PC_LIBS_PRIVATE = -lnghttp2 -lidn2 -lgsasl -lpsl -lssl -lcrypto -lssl -lcrypto -Wl,--enable-new-dtags -Wl,-rpath -Wl,/usr1/custom_location_1/lib -L/usr1/custom_location_1/lib -lgssapi -lldap -llber -lz -Wl,--disable-new-dtags ... and ... LIBS = -lnghttp2 -lidn2 -lgsasl -lpsl -lssl -lcrypto -lssl -lcrypto -Wl,--enable-new-dtags -Wl,-rpath -Wl,/usr1/custom_location_1/lib -L/usr1/custom_location_1/heimdal/lib -lgssapi -lldap -llber -lz -Wl,--disable-new-dtags With said "Makefile" variables defined as such, the subsequent CURL "make" and "make install" steps resulted in a "curl" binary that abided by RPATH rules. But, at best, we view the above solution as something of a hack. Would anybody be able to offer any clues into why the "--enable-new-dtags" might be showing up in the generated "Makefile" in the first place when I believe the build process has been definitive in expressing "--disable-new-dtags" as the linker flag that is to be used? Thanks in advance for an insight that you might be able to provide. Best regards, Steve Underwood
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.html
