Re: No more Libtool (long)
Hrvoje Niksic wrote: Google doesn't show even nearly enough hits when you search for libtool sucks. Because it's an understatement. :-) -- .-. .-.Yes, I am an agent of Satan, but my duties are largely (_ \ / _) ceremonial. | |[EMAIL PROTECTED]
Re: No more Libtool (long)
On Sat, 25 Jun 2005, Hrvoje Niksic wrote: Despite the apparent consensus that it should be integrated in Autoconf, the integration never materialized. When I queried about this in 2003 (http://tinyurl.com/a63lc), the single response charmingly told me that the solution is libtool. I now think the appropriate answer to that should have been, Libtool -- just say NO! Well, this is certainly an overstatement, but you certainly have a point. The idea behind libtool is good and the implementation is reasonable. Bugs are of course inevitable and you shouldn't be surprised seeing them especially as on exotic platforms (you even admit you've never been able to reproduce some of the other's problems on your systems). GNU software relies on public testing, but unfortunately many users fail to provide useful reports for bugs they spot and for those exotic platforms it may mean nobody ever knows about them. You're certainly right C++/Fortran/whatever tests are superfluous, not only for wget -- they should probably only be enabled on demand, like GCJ tests already are. That should qualify as a bug -- but have you filed it to the libtool team? You mentioned the lack of documentation, but it doesn't appear magically by itself, does it? Perhaps nobody else tried to use libtool like wget did. Yours could be a useful experience -- have you considered submitting your results for inclusion? Having said that I have to admit you are probably right with your decision -- OpenSSL are not libtool libraries and this is probably the most important cause of problems. For building programs rather than libraries themselves libtool is most useful when libtool libraries are involved. In this case for example it can help with pulling dependencies for static libraries (archives) that do not record that information themselves. With non-libtool libraries you need to discover it yourself anyway. Finally, there are so many people complaining about libtool -- but how many of them actually did anything to make it better? Of these, how many failed to achieve their goal due to a conceptual problem with libtool? -- only these can actually claim they have rights to blame libtool. Everyone else please either file bug reports (or better yet fix bugs you trip over) or keep silent. Maciej
Re: No more Libtool (long)
Maciej W. Rozycki [EMAIL PROTECTED] writes: Bugs are of course inevitable and you shouldn't be surprised seeing them especially as on exotic platforms (you even admit you've never been able to reproduce some of the other's problems on your systems). Please note that a platform doesn't qualify as exotic just because I don't currently have access to it. I have regular access to only Linux and Solaris. Finally, there are so many people complaining about libtool -- but how many of them actually did anything to make it better? I haven't tried to make it better partly because I wasn't convinced that Libtool was the right tool for the problem to begin with. As soon as a more focused alternative solution appeared, I used it and I think it was the right decision. Of these, how many failed to achieve their goal due to a conceptual problem with libtool? -- only these can actually claim they have rights to blame libtool. Everyone else please either file bug reports (or better yet fix bugs you trip over) or keep silent. Sorry, I find that my time is more productively spent doing other things. And I don't accept the position that one has to *earn* his right to speak of Libtool's shortcomings, or that others should keep silent just because they don't have the inclination to work on it.
Re: No more Libtool (long)
On Mon, 27 Jun 2005, Hrvoje Niksic wrote: Bugs are of course inevitable and you shouldn't be surprised seeing them especially as on exotic platforms (you even admit you've never been able to reproduce some of the other's problems on your systems). Please note that a platform doesn't qualify as exotic just because I don't currently have access to it. I have regular access to only Linux and Solaris. Well, it's exotic to you in the sense you rely on others testing it for you. Of these, how many failed to achieve their goal due to a conceptual problem with libtool? -- only these can actually claim they have rights to blame libtool. Everyone else please either file bug reports (or better yet fix bugs you trip over) or keep silent. Sorry, I find that my time is more productively spent doing other things. And I don't accept the position that one has to *earn* his right to speak of Libtool's shortcomings, or that others should keep silent just because they don't have the inclination to work on it. Certainly you may speak of its (and anything else's) shortcomings, state facts, etc. But to say it's broken you need to earn the right. Note that I haven't addressed the concern (most) specifically to you -- as a maintainer of a program who attempted to use libtool you have the right to express your experiences -- but there are a lot of others who just make a judgement on libtool based on their single-shot experience with their pet system (or perhaps even someone else's opinion). Also for most projects integrating libtool is almost as simple as placing AC_PROG_LIBTOOL into their configure.ac template. And it works. Even for so complicated setups as GCC, including cross-builds when some parts are built multiple times for different hosts. Libtool did fail for me a few times, but it was always due to a bug, not a design decision and my patches or proposals for fixes have always been welcomed warmly. Maciej
RE: No more Libtool (long)
This is the kind of obnoxious commentary I've learned to expect from glibc's maintainers. It's no more becoming from you (or anyone else). Buzz off. Mark Post -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej W. Rozycki Sent: Monday, June 27, 2005 8:01 AM To: Hrvoje Niksic Cc: wget@sunsite.dk Subject: Re: No more Libtool (long) -snip- Everyone else please either file bug reports (or better yet fix bugs you trip over) or keep silent.
RE: No more Libtool (long)
On Mon, 27 Jun 2005, Post, Mark K wrote: This is the kind of obnoxious commentary I've learned to expect from glibc's maintainers. It's no more becoming from you (or anyone else). Well, but unlike with glibc, maintainers of libtool do actually handle problems reported by users. But they have to know about them first. And no, it does not mean telling them there are problems in general -- that they already know for sure -- they need specific details as crystal balls are a scarce resource these days. Of course in theory you can debug software by proof-reading, but even that requires knowledge of external interactions. Like every GNU project libtool relies on user feedback. And fortunately some people actually do support it one way or another within their skills rather than complain (what a waste of time!). Please note the glibc approach is specific, which is regrettable, but that's nothing that can be changed easily. Buzz off. Let's focus on technical issues rather than making it personal, OK? Maciej
RE: No more Libtool (long)
You already blew that opportunity when you told us to shut up. Blame yourself. Mark Post -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej W. Rozycki Sent: Monday, June 27, 2005 11:15 AM To: Post, Mark K Cc: wget@sunsite.dk Subject: RE: No more Libtool (long) -snip- Let's focus on technical issues rather than making it personal, OK? Maciej
RE: No more Libtool (long)
I read the entire message, but I probably didn't have to. My experience with libtool in packages that really are building libraries has been pretty painful. Since wget doesn't build any, getting rid of it is one less thing to kill my builds in the future. Congratulations. Mark Post -Original Message- From: Hrvoje Niksic [mailto:[EMAIL PROTECTED] Sent: Friday, June 24, 2005 8:11 PM To: wget@sunsite.dk Subject: No more Libtool (long) Thanks to the effort of Mauro Tortonesi and the prior work of Bruno Haible, Wget has been modified to no longer use Libtool for linking in external libraries. If you are interested in why that might be a cause for celebration, read on.
Re: No more Libtool (long)
Post, Mark K [EMAIL PROTECTED] writes: I read the entire message, but I probably didn't have to. My experience with libtool in packages that really are building libraries has been pretty painful. Since wget doesn't build any, getting rid of it is one less thing to kill my builds in the future. Good to know that I'm not the only one harboring -- doubts -- towards Libtool. Google doesn't show even nearly enough hits when you search for libtool sucks. Congratulations. Thanks.
No more Libtool (long)
Thanks to the effort of Mauro Tortonesi and the prior work of Bruno Haible, Wget has been modified to no longer use Libtool for linking in external libraries. If you are interested in why that might be a cause for celebration, read on. A bit of history: Libtool was integrated in Wget by Dan Harkless, despite protests (see http://tinyurl.com/98zkt), to ensure portable linking to external libraries. Linking with a system library, such as librt or libpthread is as easy as using -lLIBNAME. However, linking to third-party libraries installed in /usr/local/lib or elsewhere is harder because: a) you have to find the location of the library, and b) you have to produce an executable with runtime path information to find the library when it is run (the system's dynamic linker cannot be expected to know about non-standard library locations). The b) part is really tricky because the compiler and linker flags vary from system to system, and it is hard or impossible to get access to a large number of different systems to test it on. For example, on Linux you would use -Wl,-rpath /usr/local/lib, on Solaris you would use -R/usr/local/lib, on AIX you might use -Wl,-blibpath /usr/local/lib:/usr/lib:/lib, and so on. Of course, the -Wl, part also differs between compilers. And the GNU linker may be used by GCC on some of the systems, which means you have to use its flags, not the system ones. And so on -- you get the idea. Libtool, normally used for *building* shared libraries, can also be used to help link them in because it contains code that handles the above runpath conundrum. It supports a unified interface where make can simply use -R/usr/local/lib, and depend on libtool to convert that to the incantation appropriate for the system linker. configure.in was made to detect OpenSSL in this way; however, what started as a simple use of libtool turned into 200 lines of *hard* configure.in code. Despite the apparent improvement over simply not specifying the runpath, and arguably over trying to duplicate libtool's rpath logic in configure.in, Libtool brought many painful disadvantages, which I will proceed to list, in no particular order: * It made the configure script much larger and slower, excercising many weird and unnecessary checks, such as how to run one of ~20 supported FORTRAN compilers, how to parse output of `nm', how to run the C++ preprocessor, where to find `ar', `ranlib', and `strip', how to produce PIC, how to tell C++ not to use RTTI and exceptions (!), and so on. * It is unclear what would happen if some of the checks Libtool thinks are important (the nm one comes to mind) failed on a platform on which the rest of Wget builds just fine. The experience with a Libtool version that caused Wget to fail to build when there was no C++ compiler on the platform suggests the worst. * Such use of Libtool is complete overkill. While Libtool may be the appropriate solution for building shared libraries (although there are opposing views to that), it was certainly not designed with this use in mind, which is amply proven by the amount of documentation devoted to the issue -- none. * The merge of Wget's configure and libtool was far from clean, simply because such use was not envisioned and is therefore not documented. It involved digging into Autoconf internals, such as unsetting cache-related variables, temporarily changing CC to $SHELL ./libtool $CC and then reverting it, hackery to LDFLAGS and LIBS, and more. * It was completely specific to OpenSSL's libssl and libcrypto, and non-reusable to other external libraries. Adding a *new* external library would have required rethinking the entire scheme, and possibly rewriting that very tricky code. * Libtool created unnecessary cruft, such as the .libs directories, and unnecessary restrictions, such as the inability to use `make CC=some-other-compiler' without rerunning configure, even though the other compiler would work just fine with the Makefile variables currently available -- for example, it can be another version of gcc. (This had to do with the tags feature of Libtool that the documentation didn't explain sufficiently to turn it off.) * The complex and fragile Libtool code base required frequent updates. Some versions of Wget didn't compile on otherwise unexceptional operating systems simply because of Libtool bugs. While it can be argued that all software requires updates in one form or another, Libtool has required much more hand-holding than other software we use to build Wget, for example Autoconf. * IT DIDN'T WORK, despite all the invested effort. After Wget 1.10 was released, this list received reports of OpenSSL libraries not being detected on some operating systems, apparently because Libtool insisted on creating executable in the .libs directory (where the Autoconf test system doesn't find them). Of course, Libtool doesn't do that on Linux, nor on
