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

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Wed, Apr 06, 2005 at 05:02:15PM CEST:
> Ralf Wildenhues wrote:
> 
> >>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.
> 
> True, but if the default case is to continue with what we do already, then it
> will a) be better than our current demo-hardcode test b) be easier to maintain
> because it will be clear which code is needed for each platform that is an
> exception.

OK.  I will introduce dumpstabs only, that should delimit it to Solaris.
Plus a big comment explaining why we need it.

> > 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.
> 
> Okay, if you prefer that approach, I have no problem as long as we keep track
> of why the various extra tools are needed (in this case, something about
> solaris embedding the compiler command in debug data, requiring something
> other than grep to avoid false positives).

Also agreed.

> > 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).
> 
> Since this is for the testsuite, and doesn't affect the functionality of what
> we install, I think we can afford a little more leniancy when worrying about
> stability.

Alright, thanks.

> > For another, I don't really like putting different things into the
> > different branches unless really necessary.  Too many bugreports
> > necessitating backports.  :(
> 
> Well, that is the point of having branches in the first place!

Sure, to some extent.

> The real problem is that we have allowed ourselves to be sucked into
> continuing to support branch-1-5, which means that effort we should be
> spending on fixing the last few bugs in branch-2-0 is wasted in backporting
> fixes to an essentially deprecated tree.

This I cannot agree with.  None of the distributions I know ship libtool
branch-2-0 or higher (Debian experimental does not count as shipping).
While I would love to deny all work on branch-1-5, I find it very much
irresponsible to ignore bugreports against it.  As I said before: As
soon as branch-2-0 is usable by the general libtool audience (including
Sander; and Bob on mingw :), and we think we are fine on the regression
side of things, I will not work on branch-1-5 any more.

OTOH, if you look at the bugs I fixed on branch-1-5: Many are open bugs
in branch-2-0 and HEAD as well.  Backporting is a small part of working
on bugreports at all.


FYI: I have applied the attached patches to all branches (the HEAD one
goes for branch-2-0 as well).

Regards,
Ralf

        * tests/demo-hardcode.test [solaris]:  Use dumpstabs if available,
        to avoid false failure caused by debug section which contains
        command line (Solaris cc).

hardcode-HEAD
Description: Text document

hardcode-branch-1-5
Description: Text document