BTW: which one is the official list address? @thep or @zino? Which other aliases exist, so I don't have to second-guess my MUA settings -- thanks. * Richard B. Kreckel wrote on Thu, Mar 17, 2005 at 01:04:21AM CET:
On Wed, 16 Mar 2005, Ralf Wildenhues wrote:
* Richard B. Kreckel wrote on Tue, Mar 15, 2005 at 10:07:10PM CET:
As to updateing libtool. Last time I tried (maybe two years ago) it turned out to be kinda nightmarish. IIRC, it tried to link the shared library with ld -r and there appeared to be a superlinear algorithm somewhere. I interrupted it after some hours when it had ony finished several hundred of the 855 objects.
For a decent bugreport this is missing
It wasn't meant to be a bugreport. It was an attempt to avoid work. :-)
On a bad-mooded day I'd be calling it FUD.. never mind. :)
- `configure' output, esp. | checking the maximum length of command line arguments...
Huh, why's that of interest? Anyway, it's 32768. But you know already.
Well, that's quite important. It's deducible from the system, sure (unless there is a bug in the macro that calculates the length). If your link line turns out to be longer than that maximum length estimate, libtool _will_ split the link by using `ld -r', possibly more than once. It's one portable way around that restriction. On some systems, convenience archives could help, too.
Most likely the superlinearity is due to the linker, not to Libtool.
I remember that this was my impression, too: some worse-than-O(1) behavior in ld -i made the loop over src/*.o superlinear.
ACK.
Well. A couple of months ago I put some patches into the HEAD version of Libtool to make it link libcln.la more efficiently.
What are these patches doing?
For linking libcln.la, most of the time was spent in quoting the command line parameters with some quoted_foo=`$ECHO X"$foo" | $Xsed $somesubst` in some func_quote_foo shell function. I changed configure to enable either this portable version, or, in case $CONFIG_SHELL understands some XSI (like ${foo##*/}), to use a function that does not fork instead. For the common case, most forks which scale with the number of input objects are thus removed. There might be one left, I don't remember. Note Libtool HEAD is what will eventually be 2.2.x. As I said, however, these patches might get their way into 2.0.x. Not 1.5.x by any means, because they depend on a lot of cleanup that happened after 1.5.x.
I did not work on the piecewise linking part, because that did not happen to me. For the shell (libtool script execution) part, I did, however, cut the time down to about 30% of the time libtool-1.5.x takes.
Anyway, back to your original suggestion to upgrade libtool: To which version? 1.5.14? I had completely forgotten that Bruno has already upgraded libtool to version 1.5.6 and the problem with piecewise linking I had experienced earlier seems to have gone.
Stable is 1.5.14. No date for 2.0.0, it's been "soon to come" for years now. :-/ There have been no big changes in the 1.5.x series since 1.5.6 except mostly compiler knowledge updates. As such it would make sense to update just so some lesser-used or newer systems are supported better.
And as to the modifications in CLN's libtool, there appears to be only one patch for the Comeau compiler:
--- libtool-1.5.6/libtool.m4 2004-04-02 05:46:14.000000000 +0200 +++ /home/rbk/projects/cln/m4/libtool.m4 2004-08-25 14:13:10.000000000 +0200 @@ -4901,6 +4901,9 @@ # All Alpha code is PIC. _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared' ;; + como) + _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-lopt=' + ;; esac ;;
Why not include it upstream?
Sure. Do you have a ChangeLog entry for it as well? Weird enough, I have not found this option to be described in Comeau's online documentation. For whoever has Comeau: it'd be really nice if they ran the whole Libtool testsuite (preferably branch-2-0) on it, I'm sure there are more issues to sort out. Libtool supporting more compilers better is always a good thing. Regards, and sorry if some of it sounded like an advertisement, Ralf