Configure option --with-gssapi=path does not work anymore without pkg-config

[mkauf]

I did this

I have used the "configure" option --with-gssapi=path to specify the MIT Kerberos to use for GSS API.

This does not work anymore, because pull request #7916 has introduced a bug: When the option --with-gssapi=path is used, the configure script tries to use pkg-config anyway. If pkg-config is not available, or if pkg-config does not find the necessary information, it is assumed that the GSS library's name is "gssapi". But the correct name (in my case) is "gssapi_krb5".

The configure script prints a (seemingly) unrelated error:

checking OpenSSL linking with -ldl... no
checking OpenSSL linking with -ldl and -lpthread... no
configure: OPT_OPENSSL: yes
configure: OPENSSL_ENABLED: 
configure: error: --with-openssl was given but OpenSSL could not be detected

From config.log:

configure:25314: checking OpenSSL linking with -ldl and -lpthread
[...]
ld: cannot find -lgssapi

I think that pkg-config should only be used if --with-gssapi is specified without a path, but it should not be used if a path is present. Probably the tool krb5-config should be used in this case to detect the GSS library's name.

I expected the following

configure should not abort with an error

curl/libcurl version

curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/1.1.1m zlib/1.2.11
Release-Date: 2022-01-05
Protocols: ftp ftps http https 
Features: alt-svc GSS-API HSTS HTTPS-proxy IPv6 Kerberos Largefile libz NTLM NTLM_WB SPNEGO SSL TLS-SRP UnixSockets

operating system

CentOS Linux release 7.9.2009 (Core)

[bagder]

think that pkg-config should only be used if --with-gssapi is specified without a path, but it should not be used if a path is present. Probably the tool krb5-config should be used in this case to detect the GSS library's name

I think we should always try pkg-config first, both with and without path given. Simply because pkg-config is the superior way for this kind of data. But if there is no pkg-config available or if gssapi is not supported by it, we should continue to try krb5-config next and then go best-effort without.

[dfandrich]

IMHO, if the user is supplying a path, it's there for a reason and should be used. My expectation as a user would be, if no path is given, for it to first use pkg-config then fall back to some default location, but if a path is given to use that and fail if the path doesn't work.

[jzakrzewski]

pkg-config may be superior but when I say "use this", I want to it to use "this". Or tell me, that I'm stupid/need more sleep. But never to try to outsmart me.

[bagder]

Yes, but many (modern) softwares install the pkg-config data in that path and it contains info that helps the build. So why not use it if its there?

[jzakrzewski]

I mean if there's :

/my/gss/install
   - bin
   - lib
       - pkgconfig
   - include

(or however it's organised)
then sure - use THAT. If that's false, it's my fault. But if I give a path and it uses some system-wide configuration, that's highly unexpected and will cause people hours of debugging sometimes.

[dfandrich]

On Tue, Jan 18, 2022 at 01:06:46AM -0800, Daniel Stenberg wrote: Yes, but many (modern) softwares install the pkg-config data in that path and it contains info that helps the build. So why not use it if its there?

Because that's the system-supplied library whereas the user wants to use a local one.

[ripplehang]

I met the same issue, I needs to customized the gssapi lib in my case,
so the quick workaround is to rollback the pr:#7916 in my local environment?

[asedeno]

But if I give a path and it uses some system-wide configuration, that's highly unexpected and will cause people hours of debugging sometimes.

Hi, this is me today.

[asedeno]

I dug into this a bit more since I'm having the same problems with curl 7.80.0+, and unfortunately just locally reverting #7916 is not enough for me because I'm building on an older platform that doesn't have a new enough autotools to regenerate configure. I depend on the tarball releases and packaged configure scripts which are now broken for me.