Re: Make -Wc,foo behave like -Xcompiler foo in link mode.

[Peter Rosin]

Den 2009-09-07 21:09 skrev Ralf Wildenhues:
> > > +  eval "`$LIBTOOL --tag=$tag --config | $EGREP 
> > > '^(wl|archive_cmds|reload_cmds)='`"
> > You are not using $reload_cmds anywhere.
>
> Indeed; I added it because I thought of running a reload command, until
> I realized that it wouldn't contain these flags anyway.  Removing it.
> Thanks.

Still there :-)

> [...]
> > > +    done
> > > +  done
> > > +done
> > > +
> > > +AT_CLEANUP
> > There needs to be some markers about what is being done when
> > there is a repetetive loop like this (48 times through the
> > innermost loop in the "worst case"). I remember hardship
> > trying to deduce exactly what failed when I had a failure
> > inside stresstest.at...
>
> Yeah, stresstest is ugly to debug.  I always run with -v -x to get as
> many clues as possible.  But if you'd like to add more markers, feel
> free to.
>
> > An example: If the following line fails, the test as written
> > doesn't give too many hints as to what it's trying to do:
> >
> > ../../tests/flags.at:89: $LIBTOOL -n --tag=$tag --mode=link $link              
> > -o $output a.lo -rpath /nowhere $flag-foo
> >
> > Maybe it's as simple as using LT_AT_CHECK instead of AT_CHECK?
>
> Well, the following already splits it up into four tests with 12
> commands each.  Maybe that is enough to make it feasible?

Adding -x really helps, thanks for the hint! But it isn't really
optimal when all commands seem to originate from line 24. E.g.

../../tests/flags.at:24: { test -n "$CC" && test "X$CC" != Xno; } || (exit 77)
../../tests/flags.at:24: $LIBTOOL --tag=CC --mode=compile $compile -c $source
../../tests/flags.at:24: $LIBTOOL -n --tag=CC --mode=compile $compile        
$flag-foo -c $source
../../tests/flags.at:24: $FGREP " -foo" stdout
../../tests/flags.at:24: $LIBTOOL -n --tag=CC --mode=link $link              -o 
$output a.lo -rpath /nowhere $flag-foo

But the test isn't that long so not a major problem.

> Does it pass for you?

Yes. gcc-3.4/cygwin-1.5 and msvc/msys are both ok. At least after I
apply my "-Wc,"-patch, didn't have that originally on the msvc branch
which threw me off track for a while... So, I can report that the test
only seems to catch the original bug if $wl is non-empty. Probably
good enough though...

Cheers,
Peter