Re: darwin: mix up of .dylib and .bundle

[Christoph Egger]

> Christoph Egger wrote:
> | Hi!
> |
> | libtool mixes up .dylib and .bundle. It thinks,
> | .dylib are modules and .bundle are shared libs.
> 
> Not here it doesn't...
>
> |
> | This causes linking failures on darwin due to multiple defined symbols,
> | in cases where libfoo.dylib is inherited from libbar.dylib
> | and the program foo links against libbar.dylib and libfoo.dylib.
> | libtool also prints a warning, "libfoo.dylib is a module, not a shared
> | library", which is wrong.

After digging deeper, I think this theory is wrong.

This issue is a pretty nasty one. It is not easy to reproduce...
See below for the details.

> | I've attached a patch against cvs head which fixes this (for me at
> | least). If the patch is not correct, then please give me one to test.
> |
> 
> I think I've seen this issue with the GNU libtool that Apple shipped (is
> shipping?),

You mean /usr/bin/libtool ? This is a binary used by gcc.

> what version of glibtool are you using? Where did it originate?

libtool cvs head

> What version of darwin?

MacOSX 10.4.2

> Or maybe it is just the fact that if there is no .dylib it
> does its best and uses the .a? Please show steps to reproduce
> too.


I've created a small lib with the exact same buildsystem the original
one use. So this small lib (I called it libtest) uses automake, autoconf
and libtool the exact same way.
See attachment: libtest.tar.gz

autoconf 2.59 and automake 1.9.6 are required.
If you use autoconf cvs and/or automake cvs than pass
the option '--force' to step 2

How to use:
1. extract && cd libtest
2. ./autogen.sh
3. ./configure
4. make
5. make install


Now the nasty thing:
The original lib has a default development tree and a experimental
tree. The difference is only (really only) in the source -
 NO diff in the buildsystem. I triple-checked to be sure.

The default tree builds w/o any errors.
The experimental tree runs into an linking error.
The libtest builds w/o any errors.

I attached the output of the same _sub_-directory of all three trees
where the experimental one fails.

1) libgii-default.output is the output from the default tree.
2) libgii-experimental.output is the output from the experimental tree.
3) libtest.output is the output from libtest.

Nonetheless, there are three different results:

1) shows how things should be.
2) libtool somehow tries to link in both shared and static versions
   into the same lib resulting into multiple definitions.
3) libtool see's the -rpath option twice...


P.S.: How about integrating libtest into libtool's testsuite?
It might uncover bugs on many other operating systems
(win32, linux, *bsd, solaris, aix, etc.)

-- 
Greetings,

Christoph

Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner

libtest.tar.gz
Description: Unix tar archive

libgii-default.output
Description: Binary data

libgii-experimental.output
Description: Binary data

libtest.output
Description: Binary data