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).
* tests/demo-hardcode.test [solaris]: Use dumpstabs if available,
to avoid false failure caused by debug section which contains
command line (Solaris cc).
Index: tests/demo-hardcode.test
===================================================================
RCS file: /cvsroot/libtool/libtool/tests/demo-hardcode.test,v
retrieving revision 1.7
diff -u -r1.7 demo-hardcode.test
--- tests/demo-hardcode.test 13 Apr 2005 12:24:35 -0000 1.7
+++ tests/demo-hardcode.test 17 Apr 2005 07:41:40 -0000
@@ -35,6 +35,9 @@
func_make "hardcode"
+# Extra tools we might need
+: ${DUMPSTABS=dumpstabs}
+
# Suck in all the hardcode_* variable settings.
func_msg "Finding libtool.m4's guesses at hardcoding values"
func_get_config 'hardcode_direct
@@ -65,6 +68,16 @@
# Discover whether the objdir really was hardcoded.
hardcoded=no
+ # Solaris cc may store the command line in a debugging section,
+ # which leads to false positives. Unfortunately, Solaris strip
+ # is not capable to remove the section (unlike GNU binutils strip).
+ # So we use dumpstabs if it seems to work.
+ if { $DUMPSTABS -d $file; } >/dev/null 2>&1; then
+ if $DUMPSTABS -d $file 2>/dev/null | $FGREP "$objdir" >/dev/null 2>&1; then
+ hardcoded=yes
+ else
+ hardcoded=no
+ fi
# At least AIX fgrep doesn't work for binary files, and AIX also
# doesn't have strings(1), so we need this strange conversion
# (which only works on ASCII).
* tests/hardcode.test [solaris]: Use dumpstabs if available,
to avoid false failure caused by debug section which contains
command line (Solaris cc).
Index: tests/hardcode.test
===================================================================
RCS file: /cvsroot/libtool/libtool/tests/Attic/hardcode.test,v
retrieving revision 1.6
diff -u -r1.6 hardcode.test
--- tests/hardcode.test 19 Nov 2002 09:42:39 -0000 1.6
+++ tests/hardcode.test 17 Apr 2005 07:37:37 -0000
@@ -10,6 +10,9 @@
fi
. $srcdir/defs || exit 1
+# Extra tools we might need
+: ${DUMPSTABS=dumpstabs}
+
# Check that things are built.
if test -f $prefix/lib/libhello.la && cd ../demo; then :
else
@@ -95,12 +98,22 @@
# Discover whether the objdir really was hardcoded.
hardcoded=no
+ # Solaris cc may store the command line in a debugging section,
+ # which leads to false positives. Unfortunately, Solaris strip
+ # is not capable to remove the section (unlike GNU binutils strip).
+ # So we use dumpstabs if it seems to work.
+ if { $DUMPSTABS -d $file; } >/dev/null 2>&1; then
+ if $DUMPSTABS -d $file 2>/dev/null | $FGREP "$objdir" >/dev/null 2>&1; then
+ hardcoded=yes
+ else
+ hardcoded=no
+ fi
# At least AIX fgrep doesn't work for binary files, and AIX also
# doesn't have strings(1), so we need this strange conversion
# (which only works on ASCII).
# AIX fgrep also has a limited line length, so we turn unprintable
# characters into newlines.
- if cat $file | (tr '\000-\037\200-\377' '\n' || cat) 2>/dev/null \
+ elif cat $file | (tr '\000-\037\200-\377' '\n' || cat) 2>/dev/null \
| $FGREP "$objdir" > /dev/null 2>&1; then
hardcoded=yes
elif $FGREP "$objdir" $file > /dev/null 2>&1; then
