libtoolized some older libs

[Charles Wilson]

> I made several /usr/lib/.la file for libs which could be loaded shared 
> (at run-time) for myself to enable shared and smaller modules for the 
> bigger stuff I'm working on. php, clamav, postgresql, ...

Whether a .la file exists or not has NO bearing on whether the library 
can be loaded dynamically (either implicitly by the windows runtime 
loader, or explicitly via dlopen()/LoadLibrary()/etc).

The .dll.a & .dll files for these packages are fine.  There is nothing 
wrong with them.

Except they weren't produced by libtool.  BFD.

Did you know that libtool's special shared library loader (libltdl) CAN, 
in fact, load libraries that AREN'T libtool-generated?  That libtool 
DOESN'T actually need the .la file?  (It's nice to have, and make 
libltdl-based usages easier, but is NOT necessary).  That libtool 
itself, CAN, actually build exes and dlls which depend on 
non-libtool-generated libraries?

> Basically I was just annoyed that such libs as -lz -lssl -lcrypto -png 
> -lncurses and so on, could not be loaded dynamically. And that I had to 
> add -no-undefined.

You always have to add -no-undefined.  That is a precondition for 
libtool to build a shared library.  It has nothing to do with whether 
you are linking against dependency that is a "regular" shared library or 
is a libtool-generated shared library.

If making these fake .la files means that you no longer need to add 
-no-undefined in YOUR makefile, then that is a serendipitous, but not 
designed, "feature" of libtool.  As such, it could go away at any time 
and you should not rely on it.

You should just push those -no-undefined changes upstream.  They won't 
hurt other platforms, and are necessary for a windows/cygwin port.  I 
can't see upstream maintainers complaining about that.

> Attached are the definitions for:
> /usr/lib/libbz2.la
> /usr/lib/libclamav.la
> /usr/lib/libcrypt.la
> /usr/lib/libcrypto.la
> /usr/lib/libcurl.la
> /usr/lib/libcurses.la
> /usr/lib/libminires.la
> /usr/lib/libncurses.la
> /usr/lib/libpng.la
> /usr/lib/libpng12.la
> /usr/lib/libresolv.la
> /usr/lib/libssl.la
> /usr/lib/libz.la
> 
> I'm quite annoyed that e.g. "openssl-devel-0.9.7d-2" or "zlib" still 
> come with lib*.dll.a, lib*.a and cyg*.dll, but still without lib*.la.

Fine.  If the presence of shared, import, AND static libs without 
libtool-specific but otherwise useless support files offends you, then 
I'll remove those packages.  Happy?

No, I didn't think so.

Let's take zlib, for instance.  zlib is ported to every platform on the 
planet.  Libtool is not.  Should the zlib maintainers require libtool? 
No, of course not.

It gets better.  Current discussions on the libtool mailing list are 
about adding extra stuff into shared libraries that are 
libtool-generated.  E.g. "if .la exists, then you can look for these 
symbols in the dll".

But your fake .la files, hacked up to *imply* that these libs were 
generated by libtool, will defeat that -- because in actual fact, the 
zlib shared lib will NOT contain those symbols.

Look, you're never going to reach libtool nirvana, where
   (a) every shared lib on the system (and static lib, for that matter) 
has a matching libtool .la file, AND
   (b) all of those libs were actually in fact BUILT by libtool

That's why libtool and libltdl both know how to link against 
non-libtool-generated libraries.  Use the feature, don't circumvent it 
by creating FAKE .la files which LIE about the provenance of the 
libraries they describe.

And I don't care if Red Hat/Mandrake/Debian/you-fav-linux-distro do add 
.la files.  They're wrong.

--
Chuck