Bugzilla Bug 95384

the /usr/lib/libpcre.la and /usr/lib/libpcreposix.la files generated after
emerge libpcre on OSX Tiger are invalid and cause problems with libtool when
compiling against them.

the properties 'dlname' and 'library_names' in the libprce.la file list the
names of the libraries without the .dylib suffix which (apparently) is needed on
OSX to make it work correctly.  The .la files for packages already available on
the system also list the libraries with '.dylib' suffix.

Reproducible: Always
Steps to Reproduce:
1. emerge libpcre (on OSX Panther or Tiger)
2. compile a program that links against libpcre (-lpcre) it fails
3. diff /usr/lib/libpcre.la /usr/lib/libxslt.la and notice there are no '.dylib'
suffices for the library files in the libpcre.la file

Actual Results:  
compilation failed because it could not find the file /usr/lib/libpcre, which is
correct because it doesn't exist.

Expected Results:  
the .la files generated by the ebuild (Portage?) should somehow include the
.dylib suffix so libtool correctly starts looking for /usr/lib/libpcre.dylib
which *does* exist after emerge libpcre.

ok.

now this might/might not help.  I can't really find what the elibtool action
does, but perhaps it's just a matter of using glibtool and glibtoolize instead
of libtool on OSX.  Alternative is to patch libtool's output, but I think this
problem will be for any package that uses glibtool on Darwin/OSX.

Mmm - definitely don't want to patch libtool's output. That's too hackish even
for me.
elibtoolize can be found in /usr/portage/eclass/libtool.eclass, or for the
lazy, man libtool.eclass.
On ppc-macos, it calls glibtoolize with --copy and --force, as well as
darwintoolize, also defined
in libtool.eclass.

ah, that explains why I couldn't find the eclass... locate doesn't search NFS
mounts (luckily!).

I'm not familiar enough with the many patches and fixes applied there to see
what's wrong.

However:
I just commented out elibtoolize in the libpcre-5.0 ebuild to see what it would
do by default... and guess?  It generated a nice /usr/lib/libpcre.la file with
the necessary .dylib suffix.

Calling darwintoolize instead of elibtoolize seems to fix the problem. I'm not
willing to commit on it yet
because this may be part of a larger problem with elibtoolize that affects
multiple packages. I'd like to
know exactly what it is in elibtoolize that's causing the problem and more
importantly why.

In another package, I saw darwintoolize being called directly too.  I think it
was the libmng one, or jpeg...  So it seems to be done elsewhere.  (if it makes
sense to you)

After talking with kito, I'm going to remove elibtoolize entirely. It doesn't
seem to be necessary for ppc-
macos.