[CLN-list] CLN on OS X, linking problem

[Ralf Wildenhues]

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