Re: libtool 1.4.2 on Darwin

[Benjamin Reed]

On Wed, 2002-10-09 at 16:15, Robert Boehne wrote:
> Christoph,
> 
> The patch against libtool.m4 is different from what is in
> CVS branch-1-4.  Does today's branch-1-4 have the problem
> your patch intends to fix?  It appears that this may
> be fixed in CVS.
>   If you would, please get Libtool cvs branch-1-4, if you
> don't have access to it for some reason, send me an email
> (directly) and I'll mail you a tarball.

OK, here's essentially the same patch but against the 1.4 tree.

Another thing I was wondering, while I'm at it.  Darwin has a strange
behavior in that there are two different ways that symbols can be
created for the dynamic loader, either "flat" namespace, or "twolevel"
namespace.  It has something to do with the prebinding support that's
built into the library dynamic loader for darwin and symbol clashes
between libraries.

(for more on what this means, see:)
http://developer.apple.com/techpubs/macosx/ReleaseNotes/TwoLevelNamespaces.html

Currently libtool forces it to the flat namespace, which will fix
compilation with some older software that wasn't written with prebinding
in mind, but it's really non-optimal.  Is there any way we could add
support for some type of command-line option to choose the twolevel
namespace?  There is currently no way to choose at build time other than
to hack libtool, which is very non-optimal (and also means that the
Darwin KDE tree could never be fully integrated into KDE mainline, since
they will only accept libtool changes that have been accepted into
libtool CVS or a release).

I'm not sure if you have any way (or more importantly, if it
breaks/bends libtools goals) of adding platform-specific flags or some
other way to implementing choosing the namespace behaviour at link time,
but that would be incredibly helpful.  Forcing everything to a flat
namespace is really a workaround for libraries that are doing dodgy
things with public symbols, from what I understand.

libtool14-darwin.patch
Description: Text document