On Mon, Oct 6, 2025, 12:20 Steve Underwood via curl-users < [email protected]> wrote:
> 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 On your Amazon Linux, what do you get from `krb5-config --libs gssapi` ?
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.html
