Re: cmdline_wrap.at

[Tim Rice]

Hi Ralf,

On Sat, 21 Feb 2009, Ralf Wildenhues wrote:

> Hi Tim,
> 
> * 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.

> > so now the only failure is the "low max_cmd_len" test.
> 
> OK, cool.
> 
> > I guess I don't really know what cmdline_wrap.at is trying to acomplish.
> > And I'm puzzled why the "simple template test" fails inside cmdline_wrap
> > but not outside of it.
> 
> Well, it tries to simulate a very long command line, so long that its
> expansion by libtool will exceed the kernel command line length limit.
> It does this by setting the limit very low, which libtool internally
> compares against.  So then the wrapping code branches are exercised,
> which create intermediate libraries or objects.
> 
> 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.
 
> The test case tries to re-run all kinds of other tests in our testsuite
> (exactly those that only exercise the $LIBTOOL script), for best
> possible code coverage.
> 
> 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.

     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.
--------------------------

Thanks.

> 
> Thanks!
> Ralf
> 

-- 
Tim Rice                                Multitalents    (707) 887-1469
address@hidden

uw-template.patch
Description: Text document

x.tst-without-patch
Description: Text document

x.tst-with-patch
Description: Text document