Hrvoje Niksic <[EMAIL PROTECTED]> writes:
> Dan, I'm not sure I understood exactly why libtool needs to be bundled
> with Wget. I was under the impression that the purpose of libtool was
> to facilitate _creating_ of libraries, which we don't do.
It facilitates _using_ _shared_ libraries, whether using involves making
them, linking to them, or both.
> If libtool helps us link with a system library, that's nice, but IMHO an
> overkill. Linking with existing libraries was never much of a problem.
You're right, linking with system libraries is _not_ much of a problem.
Unfortunately, linking with 3rd party shared libraries is one. Unlike the
-L/-l static library linking options that are supported by absolutely
everyone, every vendor has a slightly different standard as to how to link
in shared libraries and have them actually be found at runtime. There's -R,
-rpath, -blibpath, numerous differently-named environment variables, etc.
This doesn't come up for shared system libraries because they live in
directories that the OS always looks in at runtime. Many OSes don't give
any good way to add other directories (such as /usr/local/ssl/lib) to that
searchpath for all users.
You can assume the user has intimate knowledge of how all this works on
their particular OS, and trust they will (without any prompting from the
documentation) know how to set all the appropriate CFLAGS/LDFLAGS/LIBS
environment variables before running configure (making sure that their
settings don't overwrite needed options configure sets up by default), but
unfortunately in most cases this is not a realistic assumption.
On another project I work on, I was trying to link to the Cyrus SASL shared
library and not blow up at runtime because it can't find it in the normal
system library directories. At first I thought since I wasn't _building_
shared libraries I didn't need the full power of libtool, and I didn't feel
like spending the time to learn how to integrate it. As I started trying to
look at every OS/compiler pair I could get my hands on and write this
functionality into configure and the Makefiles, though, someone pointed out
that I was reinventing the wheel and that I should just use libtool, whose
whole reason for existence is this stuff. I now completely agree.
> The configure process is now extended with a bunch of unnecessary
> things (`gcc -no-rtti -no-exceptions'?),
Eh? Those are C++-specfic options and they didn't show up when I tested
this on AIX, Linux, and Solaris. We should look into that (though the
options shouldn't actually hurt anything).
> and there is an empty
> `.libs/' directory, which is empty because we don't really need it.
An empty hidden directory created during the build process doesn't bother me
all that much -- sorry.
> Besides, bundling libtool is one more maintenance responsibility -- we
> have to track maintainer releases and update it.
Considering the config.guess and config.sub scripts sat unmaintained from
1996 until a few days ago, and no one apparently ever noticed or complained
in all that time, I'd say keeping libtool up-to-date won't be a big problem
in practice.
> Is there a reason why libtool is needed that I'm missing?
Just the addition of OpenSSL support.
---------------------------------------------------------------
Dan Harkless | To help prevent SPAM contamination,
GNU Wget co-maintainer | please do not mention this email
http://sunsite.dk/wget/ | address in Usenet posts -- thank you.
