Re: improve demo-hardcode (e.g. on Solaris)

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Tue, Apr 05, 2005 at 03:43:32PM CEST:
> Ralf Wildenhues wrote:
> > Several people (I Cc:ed a couple) have reported spurious failures of
> > demo-hardcode.test on some Solaris boxen.  I believe they are all bogus
> > and caused by the compiler or putting the command line into the output
> > (or something similar).
> 
> :-(

The command line is in some extended debugging section.  I can remove it
by stripping the library with GNU binutils' strip.  Solaris' strip does
not remove the section, no matter which of the few options I throw at
it.  :(

So, unfortunately, using $striplib won't generally work either.  I had
this as an intermediate solution.

> The test was written in that way so that only one code path needed to be
> debugged, and would then be useful on all libtool supported archs.  Since that
> philosophy appears to be breaking down, I suggest that we put the test in a
> big `case $host_os in' block and do the right thing on each platform.

That will be much more work, though, and error-prone for new systems[1].
It's not so clear to me, either.  Solaris installations could have GNU
binutils objdump installed, for example.  We might want to prefer it if
it was available.

My approach is rather autoconf-like: if the tool is available and seems
to work, use it.  FWIW, I'd be happy to implement stricter functionality
checks on these tools.  Or put it someplace more suitable.

> For architectures we can't test on directly, the default case can run
> the current hardcode test (or maybe SKIP if we want to solicit more
> feedback) with a note asking for patches to add a case branch for that
> user's $host_os.

Hmm.  Don't know for sure.

> >       * tests/hardcode.test:  Use any of objdump, dumpstabs [solaris]
> >       or dump [aix] if available.
> 
> In principle I agree that this is an improvement over what we have now, and is
> an appropriate fix for the stable branch.  When porting to HEAD, I think we
> can be clearer about what we are doing by using the case approach.

Two things: I can remove both objdump and dump from my fix, as I only
know of failures on Solaris right now (will go and check the archives
though, before I commit).

For another, I don't really like putting different things into the
different branches unless really necessary.  Too many bugreports
necessitating backports.  :(
OTOH, I understand that even my patch may be considered not too stable.

Regards,
Ralf

[1] I believe quite some user frustration with Libtool stems from such
error-prone blocks.  For example linux before pass_all.