Further to this, a bit of digging into the Heimdal Kerberos 7.7.1 package we are building from source revealed its source package "tools/krb5-config.in" script could be altered before the build of Heimdal Kerberos such that when its code fragment appearing as:
case "@CANONICAL_HOST@" in alpha*-dec-osf*) rpath_flag='-Wl,-rpath -Wl,';; *-*-hpux*) rpath_flag='-Wl,+b,';; *-*-irix* | mips-*-netbsd*) rpath_flag='-Wl,-rpath -Wl,';; *-*-netbsd* | *-*-openbsd* | *-*-solaris*) rpath_flag='-R';; *-*-linux* | *-*-gnu* | *-*-k*bsd*-gnu | *-*-freebsd*) rpath_flag='-Wl,--enable-new-dtags -Wl,-rpath -Wl,';; *-*-aix*) rpath_flag='-Wl,-blibpath:';; *) rpath_flag=;; esac is instead altered to appear as: case "@CANONICAL_HOST@" in alpha*-dec-osf*) rpath_flag='-Wl,-rpath -Wl,';; *-*-hpux*) rpath_flag='-Wl,+b,';; *-*-irix* | mips-*-netbsd*) rpath_flag='-Wl,-rpath -Wl,';; *-*-netbsd* | *-*-openbsd* | *-*-solaris*) rpath_flag='-R';; *-*-linux* | *-*-gnu* | *-*-k*bsd*-gnu | *-*-freebsd*) rpath_flag='-Wl,--disable-new-dtags -Wl,-rpath -Wl,';; *-*-aix*) rpath_flag='-Wl,-blibpath:';; *) rpath_flag=;; esac then the "krb5-config" script assembled/installed from the build of Heimdal will produce output of: -Wl,--disable-new-dtags -Wl,-rpath -Wl,/usr1/vtk-2.2-dev/heimdal/lib -L/usr1/vtk-2.2-dev/heimdal/lib -lgssapi when invoked as "krb5-config --libs gssapi". With the "krb5-config" script generating such output, specifying the "--with-gssapi=..." option during a build of CURL will not, by itself, cause the resulting "curl" binary to use RUNPATH shared-library location resolution. Of course, if one is neither building Heimdal Kerberos from source nor wants to bother with its rebuild, one could simply alter the installed "krb5-config" script such that its code fragment appearing as: rpath_flag='-Wl,--enable-new-dtags -Wl,-rpath -Wl,' to instead be: rpath_flag='-Wl,--disable-new-dtags -Wl,-rpath -Wl,' to accomplish the same thing. It is hoped the above may prove helpful to others that might find themselves in a predicament similar to that in which I found myself. Again, many thanks to Hans for providing the clue that broke this open for me. Steve From: curl-users <[email protected]> On Behalf Of Steve Underwood via curl-users Sent: Friday, October 10, 2025 9:51 AM To: Hans Henrik Bergan <[email protected]>; curl-users - the curl tool <[email protected]> Cc: Steve Underwood <[email protected]> Subject: RE: CURL build issue regarding RPATH vs RUNPATH functionality 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 <[email protected]<mailto:[email protected]>> Sent: Friday, October 10, 2025 12:17 AM To: curl-users - the curl tool <[email protected]<mailto:[email protected]>> Cc: Steve Underwood <[email protected]<mailto:[email protected]>> Subject: Re: CURL build issue regarding RPATH vs RUNPATH functionality On Mon, Oct 6, 2025, 12:20 Steve Underwood via curl-users <[email protected]<mailto:[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
