Re: cmdline_wrap.at

[Ralf Wildenhues]

Hi Tim,

* Tim Rice wrote on Mon, Feb 23, 2009 at 10:47:49PM CET:
> On Sat, 21 Feb 2009, Ralf Wildenhues wrote:
> > * Tim Rice wrote on Fri, Feb 20, 2009 at 09:29:40PM CET:
> > > 
> > > I'm trying to understand the cmdline_wrap.at test.
> > > I've added this patch to fix the 2 template tests that were failing
> > > on UnixWare 7.1.4
> > 
> > Can you post the verbose output of the test both without and with the
> > patch?  Thanks.
> >   gmake check-local TESTSUITEFLAGS='-k "simple template test" -v -d -x'
> 
> Sure, attched as x.tst-without-patch & x.tst-with-patch
> I've also attached the curent patch I'm using as uw-template.patch
> It's just a s/CXX/CC/ of the old one.

How come there is no ranlib step in old_archive_cmds?
Otherwise, if it causes no other testsuite regressions, it looks good to
me.

> > How long is the actual command line length limit on your system?
> > If it is >1MB or unlimited, then this is unlikely to ever be a problem
> > in practice, and you can ignore the failure.  But some systems have
> > pretty low limits.
> 
> On my system it is 131072 but it is a kernel tunable and the default
> out of the box is 32k.

That's too low for some packages.

> > The output of the failing/passing of the test above may help analyze the
> > failure of the cmdline_wrap test.
> 
> John Wolfe was looking at this too (using 2.2.6) and here is what
> he had to say
> --------------------------
> I know why test 73 (small command line) test fails on #62 (C++
> templates).  
> 
>    - one of the link lines (second) linking against a .la, gets
> broken up and .o's are collected in a relocatable object using.
>  
>              /bin/ld -r
> 
>      Ergo the problem, the prelink phase is skipped.  It is not a
> problem with the archive being built, since $AR can accumulate
> object files, 1 file at a time.
>      So the CC -Tprelink_objects is accomplished as expected  - just
> before the $AR.
>      The prelinker command echo can be seen in the log.
> 
>      For shared objects, what is needed is to get a CC -Tprelink_objects
> done on the libobjs before they are added to the relocatable object.

Can you show how it would need to work?  If libtool reloads
  a.o b.o c.o             -> libfoo-1.o
  d.o e.o f.o libfoo-1.o  -> libfoo-2.o
and links
  g.o libfoo-2.o          -> libfoo.la

then which objects does CC -Tprelink_objects need to be run on?

>      The /bin/ld cannot be replaced with $CC since the C++ compiler
> driver will link in startup modules also.....  Soon get a multiple
> defined symbol.

Yes.

Thanks,
Ralf