#12805 closed defect (fixed)
BUG: curl +gss fails to compile
| Reported by: | MarcusCalhoun-Lopez (Marcus Calhoun-Lopez) | Owned by: | ryandesign (Ryan Carsten Schmidt) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 1.5.2 |
| Keywords: | Cc: | ryandesign (Ryan Carsten Schmidt), MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), cooljeanius (Eric Gallager) | |
| Port: | curl |
Description
The file lib/krb5.c attempts to include gssapi.h, which is not provided by the package gss. There is already a fix in the file lib/urldata.h, and the same fix can be used.
Attachments (4)
Change History (19)
Changed 17 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
| Attachment: | Portfile.diff added |
|---|
Changed 17 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
comment:1 Changed 17 years ago by ryandesign (Ryan Carsten Schmidt)
| Milestone: | → Port Bugs |
|---|
comment:2 Changed 17 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
The error was: /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I../include -I../lib -I../lib -I/opt/local/include -I/opt/local/include -I/opt/local/include -O2 -MT krb5.lo -MD -MP -MF .deps/krb5.Tpo -c krb5.c -fno-common -DPIC -o .libs/krb5.o krb5.c:55:20: error: gssapi.h: No such file or directory
As far as I can tell, the variables set by configure to control the gss library are: HAVE_GSSGNU HAVE_GSSHEIMDAL HAVE_GSSMIT
As MacPorts has opted to use GNU GSSLib, HAVE_GSSGNU is correctly set to 1. The file lib/urldata.h makes use of HAVE_GSSGNU. The file lib/krb5.c also tries to include a gss header, but does NOT make use of HAVE_GSSGNU.
This seems to me to be an error, but I am certainly no expert. At the very least it prevents compiling using MacPorts. I have not reported this upstream.
comment:3 Changed 17 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
According to the curl documentation (http://curl.haxx.se/docs/install.html), GSSAPI support requires the MIT or Heimdal Kerberos 5 packages to be installed. It makes no mention of gss.
Changing the port from gss to heimdal
- depends_lib-append port:gss
+ depends_lib-append port:heimdal fixed the compilation of "curl +gss" without any further patches.
comment:4 Changed 17 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Despite the upgrade to curl a while back, I believe this previous assertion still holds.
GSSAPI support requires the MIT or Heimdal Kerberos 5 packages (not gss).
Attached is a proposed patch.
Changed 17 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
| Attachment: | Portfile.2.diff added |
|---|
Changed 17 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
| Attachment: | Portfile.3.diff added |
|---|
comment:5 Changed 17 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
With the recent change to heimdal (r35247), I have attached yet another proposed fix.
comment:6 Changed 17 years ago by ryandesign (Ryan Carsten Schmidt)
Your new fix Portfile.3.diff makes the gss variant no longer depend on the gss port. Where does it get the gss functions from then? a gss library provided with Mac OS X? If so, is this gss library the same on 10.3, 10.4 and 10.5? If so, is there any reason not to make this functionality the default and remove the gss variant?
Or, should we use your fix Portfile.2.diff adapted for heimdal's new location?
comment:7 Changed 17 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
The gss functionality would come from Mac OS X. If I understand the explanation in #14775, heimdal is not yet known to work well with the Mac OS X kerberos implementation.
Unfortunately, I can not say how the gss implementations compare in the various Mac OS X versions. I only have access to Leopard.
Kerberos (as the GSSAPI mechanism implementation) seems to hold a strange place in MacPorts. Several port (e.g. php4, php5, nrpe, fetchmail, ...) seem to rely on the system kerberos. The postgresql port seems to rely on it inadvertently (as discussed in #14697). Kerberos seems to be an unwritten exception to the MacPorts policy of using its own libraries.
Given this, I would humbly suggest that Portfile.3.diff is an acceptable fix.
comment:8 Changed 16 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
| Cc: | mcalhoun@… added |
|---|
Cc Me!
comment:9 Changed 16 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
May I go ahead and commit the Portfile.3.diff patch?
comment:10 Changed 16 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Fixed in r43772 (maintainer timeout).
comment:12 follow-up: 14 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)
Even more fixed in r63928. (Now an already-installed gss or kerberos5 won't still get used.)
comment:13 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)
| Port: | curl added |
|---|
comment:14 Changed 11 years ago by cooljeanius (Eric Gallager)
Replying to ryandesign@…:
Even more fixed in r63928. (Now an already-installed gss or kerberos5 won't still get used.)
Wouldn't it be better to use conflicts_build-append from the conflicts_build 1.0 portgroup here instead of conflicts-append? From reading this issue, it seems to be just a build-time conflict instead of an install-time conflict, right?
What error is encountered when this patch is not present?
Does this patch need to be reported upstream? Has it been reported/fixed upstream?