Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
RE: CURL build issue regarding RPATH vs RUNPATH functionality
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Steve Underwood via curl-users <curl-users_at_lists.haxx.se>
Date: Fri, 10 Oct 2025 13:51:05 +0000
Hi Hans:
Many thanks for that insight. The output of the "krb5-config --libs gssapi " command appears as:
-Wl,--enable-new-dtags -Wl,-rpath -Wl,/usr1/<custom_location>/lib -L/usr1/<custom_location>/lib -lgssapi heimdal-gssapi.pc
It would seem when CURL is built with the "--with-gssapi=/usr1/<custom_location>" option specified, the build process utilizes "krb5-config" to obtain library details for the Kerberos functionality which is being requested for inclusion within the CURL build; something that seems reasonable given the request and which, by extension, would seem to be the source of the "--enable-new-dtags" linker flag being included the "Makefile" generated as part of CURL's autotool/automake configuration step . To confirm this, I rebuilt CURL without the "--with-gssapi=..." option and indeed, the resulting "Makefile" had no references to the "--enable-new-dtags" linker flag and the resulting "curl" binary reverted to using "RPATH" rules instead of "RUNPATH" rules for resolving shared-library locations.
Unless you're aware of another solution, if I wish to continue building CURL with embedded Kerberos support and have the resulting "curl" binary conform to RPATH shared-library resolution rules, I will need to continue altering the LIBS environment variable as mentioned in my previous post AND/OR investigate the Kerberos package that we are, like the CURL package, building from source to see if there is a way to have its resulting "krb5-config" program not include the "--enable-new-dtags" linker flag option when it is used to request library details.
Thanks again for your time and any other insight you may have.
Best regards,
Steve Underwood
From: Hans Henrik Bergan <divinity76+curl_at_gmail.com>
Sent: Friday, October 10, 2025 12:17 AM
To: curl-users - the curl tool <curl-users_at_lists.haxx.se>
Cc: Steve Underwood <steve.underwood_at_versaterm.com>
Subject: Re: CURL build issue regarding RPATH vs RUNPATH functionality
On Mon, Oct 6, 2025, 12:20 Steve Underwood via curl-users <curl-users_at_lists.haxx.se<mailto: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
Date: Fri, 10 Oct 2025 13:51:05 +0000
Hi Hans:
Many thanks for that insight. The output of the "krb5-config --libs gssapi " command appears as:
-Wl,--enable-new-dtags -Wl,-rpath -Wl,/usr1/<custom_location>/lib -L/usr1/<custom_location>/lib -lgssapi heimdal-gssapi.pc
It would seem when CURL is built with the "--with-gssapi=/usr1/<custom_location>" option specified, the build process utilizes "krb5-config" to obtain library details for the Kerberos functionality which is being requested for inclusion within the CURL build; something that seems reasonable given the request and which, by extension, would seem to be the source of the "--enable-new-dtags" linker flag being included the "Makefile" generated as part of CURL's autotool/automake configuration step . To confirm this, I rebuilt CURL without the "--with-gssapi=..." option and indeed, the resulting "Makefile" had no references to the "--enable-new-dtags" linker flag and the resulting "curl" binary reverted to using "RPATH" rules instead of "RUNPATH" rules for resolving shared-library locations.
Unless you're aware of another solution, if I wish to continue building CURL with embedded Kerberos support and have the resulting "curl" binary conform to RPATH shared-library resolution rules, I will need to continue altering the LIBS environment variable as mentioned in my previous post AND/OR investigate the Kerberos package that we are, like the CURL package, building from source to see if there is a way to have its resulting "krb5-config" program not include the "--enable-new-dtags" linker flag option when it is used to request library details.
Thanks again for your time and any other insight you may have.
Best regards,
Steve Underwood
From: Hans Henrik Bergan <divinity76+curl_at_gmail.com>
Sent: Friday, October 10, 2025 12:17 AM
To: curl-users - the curl tool <curl-users_at_lists.haxx.se>
Cc: Steve Underwood <steve.underwood_at_versaterm.com>
Subject: Re: CURL build issue regarding RPATH vs RUNPATH functionality
On Mon, Oct 6, 2025, 12:20 Steve Underwood via curl-users <curl-users_at_lists.haxx.se<mailto: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.htmlReceived on 2025-10-10