Re: CURL build issue regarding RPATH vs RUNPATH functionality

From: Hans Henrik Bergan via curl-users <curl-users_at_lists.haxx.se>
Date: Fri, 10 Oct 2025 06:16:31 +0200

On Mon, Oct 6, 2025, 12:20 Steve Underwood via curl-users <
curl-users_at_lists.haxx.se> 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

Received on 2025-10-10