Am 06.10.25 um 11:57 schrieb Steve Underwood via curl-users: > 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] > >
You can post-process your binaries with the utility "patchelf" patchelf --force-rpath --add-rpath my_rpath /path/to/my/my_exe_or_so_binary Cheers, Manfred > > 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
