neon 0.28.2 should be built without GSSAPI support

[vinc17@…]

By default, the configure script from neon looks for GSSAPI related headers. As neon does not depend on a package that provides such headers, --without-gssapi should be added to configure.args.

Also note that building neon was failing with heimdal 1.0.1_0 because heimdal provides such headers and neon doesn't like them. This problem no longer occurs because heimdal is now installed in a non-standard location. Still, adding --without-gssapi would avoid bad surprises.

If need be, a variant can still be added with a dependency on a package that provides GSSAPI and with adequate configure options.

[dluke@…]

This is the same thing as your other ticket (ie, neon used to build specifically without kerberos support but when the heimdal port was modified so that it didn't install into a location where the configure script would find and link to it, neon was changed back so that it could link with the system libs).

I'm sure we would welcome patches to base to help deal with this sort of thing in a more automated fashion.

[vinc17@…]

I'm not sure this is the same thing (at least for point 2 below): Subversion got the GSSAPI settings via /opt/local/lib/libneon.la, so it was not directly its fault.

Now, concerning neon, there are two problems:

1. Determining automatically whether changes in a dependency port affect the dependent. This needs changes in base. But this is not the problem I've reported here.

2. Consistency between the dependencies and the libraries (from MacPorts) really used, i.e. you are allowed to use a library from a port P only if you depend on P. The problem here is that if heimdal (the old version) is installed, then neon automatically detects it and links to it, even though it doesn't depend on heimdal. So, the solution I'm suggesting is to avoid this automatic detection. Many ports do this and use variants to get additional features (see e.g. the easytag port).

Now if you want to link with the system libs, then the port should make sure that the system libs are really used, not a lib provided by MacPorts.

But I don't know why you would want to link neon with the system libs. It was decided to use MacPorts provided libraries if available, for deterministic build behavior.

[dluke@…]

because it was decided that the system kerberos libs are 'special' (like the X11 libs).

[vinc17@…]

So, I assume that the fact that heimdal was installed in a standard location was a bug. But what about the kerberos5 port, which installs in a standard location?

[dluke@…]

I'm not sure, perhaps the kerberos5 port needs to be modified?

[anonymous]

Milestone Port Bugs deleted