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.
