Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
mkauf opened this issue Jan 17, 2022 · 9 comments
Closed
Labels

Comments

@mkauf
Copy link
Contributor

mkauf commented Jan 17, 2022

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 bagder added the build label Jan 17, 2022
@bagder
Copy link
Member

bagder commented Jan 17, 2022

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
Copy link
Contributor

dfandrich commented Jan 17, 2022 via email

@jzakrzewski
Copy link
Contributor

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
Copy link
Member

bagder commented Jan 18, 2022

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
Copy link
Contributor

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
Copy link
Contributor

dfandrich commented Jan 18, 2022 via email

@ripplehang
Copy link

ripplehang commented Jan 24, 2022

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
Copy link
Contributor

asedeno commented Jan 24, 2022

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
Copy link
Contributor

asedeno commented Feb 2, 2022

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.

asedeno added a commit to asedeno/curl that referenced this issue Feb 15, 2022
This reverts commit 6fe4e7d.

As per curl#8289, this breaks builds for folks with custom MIT Kerberos
installation paths.
@bagder bagder closed this as completed in 161cbc5 Feb 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

6 participants