Re: more plugin testsuite issues

[Dave Korn <dave dot korn dot cygwin at gmail dot com>]

On 26/10/2010 05:54, Alan Modra wrote:
> Hi Dave,
>   Is there a good reason why we need $LIBS in plugin.exp:58
> set libs "$LIBS $HOSTING_LIBS"

  Almost certainly not.  I verified on i686-pc-cygwin and i686-pc-linux-gnu
that nothing fails when it's removed.  Feel free to commit that change.

> I have some partial cross toolchains installed (some without even
> libc).  They all fail a number of the plugin tests due to missing -ldl
> and/or -lz, which are added to LIBS via configure.in AC_SEARCH_LIBS.
> 
> In fact, using HOSTING_LIBS and HOSTING_CRT0 in plugin.exp is a little
> confusing.  They are really only properly defined for native binutils
> (configure.host selects on $host but uses the target $CC to figure out
> startup and lib names).  Perhaps plugin.exp ought to be native only?

  It might have to be, I don't know; I don't properly understand all the ins
and outs of compiling in the testsuite.  I wanted the test to basically be the
same as doing a final link for the target platform.  That needs some kind of
crt and libs but preferably target rather than host as you so rightly point out!

  I'd like it if we could run the tests in cross as well as in native since it
only really depends on host stuff, and I could always remove the printf call
from them (or supply a stub definition somewhere), but without target libs
it's still possible for a link to fail (e.g. when a call to __main is
magically inserted at the start of main).  I don't know how to direct the
testsuite w.r.t target libs when compiling for the target using
"run_ld_link_tests".

  Hmm, maybe what would be best would be to extend the check for a compiler at
the start of plugin.exp, so that it doesn't just see if $CC is set but also
tests if it can compile a trivial exe?  Then it should just come out
unsupported on any target with no libc.

    cheers,
      DaveK