Ticket History #3887: krb5-config lists too many libraries

# Thu Jun 15 19:20:53 2006 raeburn (Ken Raeburn) - Ticket created

To:	krb5-bugs@MIT.EDU
Subject:	krb5-config lists too many libraries
From:	Ken Raeburn <raeburn@MIT.EDU>
Date:	Thu, 15 Jun 2006 19:20:10 -0400

Download (untitled) / with headers
text/plain 1.1KiB

We should have krb5-config list as few libraries as possible, when
we're building and using shared libraries. (When we've built both
shared and static, then we need to know if the user is doing a
static-only link, which implies extra command-line arguments.)

In the 1.4 releases, krb5-config listed "-lkrb5support" in its output.
That means, despite it being an internal library that only our own
libraries, and to a limited extent our applications, should be relying
on, we're now stuck with libkrb5support.0 existence (but no public
functions) being part of our ABI on most UNIX platforms.

Not the Mac -- but Mac shared library major version numbers must have
positive values, so we're about to add a platform-specific major
version number. And if we don't fix krb5-config for the 1.5 final
release, libkrb5support.1 will be part of our ABI going forward on the
Mac.

Obviously, when we build static libraries only, we'll have to list all
the MIT-supplied and native libraries we need. But since static
builds don't work currently, I'm tempted to just go remove
-lkrb5support from krb5-config now to reduce the ABI lossage on the
Mac.

# Thu Jun 15 20:26:54 2006 raeburn (Ken Raeburn) - Status changed from 'new' to 'resolved'

# Thu Jun 15 20:26:55 2006 raeburn (Ken Raeburn) - Given to raeburn (Ken Raeburn)

# Thu Jun 15 20:26:55 2006 raeburn (Ken Raeburn) - Correspondence added

From:	raeburn@mit.edu
Subject:	SVN Commit

Download (untitled) / with headers
text/plain 475B

Remove -lkrb5support, which should be for internal use only, from the displayed
list of libraries. This means the output is not suitable for linking against
static libraries built from the tree, but prevents us from committing to
keeping libkrb5support.1 in all future Mac shared-library builds (in addition
to the libkrb5support.0 we're stuck with for non-Mac UNIXy shared-library
builds).

Commit By: raeburn

Revision: 18154
Changed Files:
U trunk/src/krb5-config.in

# Thu Jun 15 20:44:47 2006 raeburn (Ken Raeburn) - Status changed from 'resolved' to 'open'

# Thu Jun 15 20:44:48 2006 raeburn (Ken Raeburn) - Comments added

Download (untitled) / with headers
text/plain 747B

I've patched around this issue for 1.5, but we should fix it better. In
particular:

Distinguish shared-library linking from static-library linking. (If we
only built one kind of library, assume that. If we built both, we
should add a command-line option, or just go with shared libraries.)

For static libraries, list all needed libraries.

For shared libraries, list only the minimal set required, on platforms
with dependencies recorded in libraries such that the OS will
automatically load the others.

Or, make a conscious decision that we've already lost this battle and
we're stuck with the set of names we've advertised already, including
the libkrb5support.1/0 hack, so we'll just keep stuffing them in every
Kerberos-using executable.

# Sat Jun 17 12:49:12 2006 hartmans (Sam Hartman) - Correspondence added

To:	raeburn@mit.edu, rt@krbdev.mit.edu
Subject:	[krbdev.mit.edu #3887] needs to be dealt with for static builds
Date:	Sat, 17 Jun 2006 12:14:52 -0400 (EDT)
From:	hartmans@mit.edu (Sam Hartman)
RT-Send-Cc:

Download (untitled) / with headers
text/plain 165B

Please open a ticket indicating that we need to deal with krb5-config
and static library builds once we support that.

Perhaps we should ship pkg-config output.

# Wed Aug 29 15:47:46 2007 raeburn (Ken Raeburn) - Comments added

Download (untitled) / with headers
text/plain 337B

Now -lkeyutils is added on Linux, if the krb5 code was built with the keyring support. This
could cause applications to needlessly depend on the keyutils library, making them unportable
to another Linux box without the keyutils library but with the same krb5 library (aside from
having been compiled without the keyutils dependency).

# Wed Aug 29 15:59:15 2007 raeburn (Ken Raeburn) - Comments added

Download (untitled) / with headers
text/plain 324B

Actually, in 1.6, we don't support static libraries, so we could just drop the indirectly-needed
libraries on *most* platforms. Since our internal build system is set up to always provide them
all, we don't have any good data at the moment on which systems might need the indirect
dependencies explicitly listed, if any.