On Mon, Jun 1, 2015 at 7:17 PM, Benjamin Kaduk <kaduk at mit.edu>
wrote:> On Sun, 31 May 2015, Don Lewis wrote:
>
>> The big culprit turned out to be ftp/curl. Even though
>> WITH_OPENSSL_PORT=yes caused it to add the openssl port as a build and
>> run dependency, it was silently getting linked to openssl from base.
The
>> cause of that problem is that the default GSSAPI_BASE option adds
>> -L/usr/lib near the start of LDFLAGS, so the linker finds the base
>> openssl libraries instead of the ones from the port. I worked around
>> that problem by switching to GSSAPI_NONE, though I tested that the
other
>> GSSAPI_* options also work correctly. There is a sanity check in the
>> Makefile that attempts to catch this conflict, but it does not work
>> correctly. See
>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200555>.
>
> My apologies for semi-hijacking your thread, but I am starting to wonder
> whether the base Heimdal (and GSSAPI) should be converted to be a private
> library. Since I am living in a MIT krb5 world, which is incompatible
> with the Heimdal libraries, I end up having some trouble trying to force
> various things to be used from base vs. ports.
>
> Making the Heimdal in base into private libraries would "solve"
the
> problem with ftp/curl, but only insamuch as it would make the GSSAPI_BASE
> option useless and require a GSSAPI from ports.
>
> -Ben
Rumour is that something like that is going to happen with all of the
problematic libraries by making them private. If someone with inside
knowledge could confirm these rumours? ;)
This leads to another question. Where is the line going to be drawn
which libraries in the base system should be private? There are
certainly some of them that have to be public like libc and the
support libraries like libusb. There is certainly no sense in making
the ports system use full set of its own libraries for everything
either.
-Kimmo