Re: libtool-1.4

[Peter Eisentraut]

Gary V. Vaughan writes:

> Failing major disasters, or the discovery of a showstopper, there are less
> than 18 hours to go before the release of libtool-1.4 from CVS HEAD.

I think that's going to be a problem for you:

libtool$ make dist
make: *** No rule to make target `ltconfig', needed by `distdir'.  Stop.

The ltconfig reference comes from automake's list of files to be
distributed if the package uses libtool.

While you can fix this by adding an empty target

ltconfig:

to Makefile.am, this bug has the possibility to become a major desaster
for automake+libtool users, as in "no more software releases until a new
automake is available".

>       I would be grateful for any host triplets (as reported by
>       the libtool configure script) on which you are able to run
>       the test suite, so that I can update the PLATFORMS file.

i586-pc-linux-gnu       All 83 tests passed
(Red Hat 7.0, gcc "2.96")


i586-sco-sysv5uw7.1.1   All 83 tests passed
(GCC 2.95.2, SCO linker)


i586-sco-sysv5uw7.1.1
Optimizing C Compilation System  (CCS) 4.0  10/23/00 (UDK FS 7.1.1b)

[...]
Making all in libltdl
        /bin/sh ./libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.     -g 
-c ltdl.c
mkdir .libs
cc -DHAVE_CONFIG_H -I. -I. -I. -g -c ltdl.c   -KPIC -DPIC -o .libs/ltdl.lo
UX:acomp: ERROR: "ltdl.c", line 1964: "inline" functions cannot use "static" 
identifier: last_error
UX:acomp: ERROR: "ltdl.c", line 1964: "inline" functions cannot use "static" 
identifier: lt_dlerror_strings
*** Error code 1 (bu21)

Once I fixed that (see below) I got 20 of 83 tests failed.  The failed
tests are always the pairs

*-exec.test
*-inst.test

leaving complaints like "cannot execute ../demo/hell.static", as well as a
few core dumps.

I'm not sure whether the compilation error is valid, but this system has
a pretty pedantic C99 compiler.  Here's a patch:

2001-04-21  Peter Eisentraut  <address@hidden>

        * libltdl/ltdl.c (trim): Don't inline.  Unixware 7.1.1's compiler
        says you can't access static variables from inline functions.

*** libltdl/ltdl.c.orig Sat Apr 21 15:35:56 2001
--- libltdl/ltdl.c      Sat Apr 21 15:39:12 2001
***************
*** 1943,1949 ****
    return errors;
  }

! static inline int
  trim (dest, str)
       char **dest;
       const char *str;
--- 1943,1949 ----
    return errors;
  }

! static int
  trim (dest, str)
       char **dest;
       const char *str;
***snip


i386-unknown-freebsd4.3 (GCC 2.95.3)

Test suite hangs in mdemo-exec.test, execution of

../mdemo/mdemo ../mdemo/foo1.la ../mdemo/libfoo2.la

at lt_dlexit(), line 1384 or thereabouts.  Looking at the surrounding code

      for (level = 1; handles; ++level)

seems to be misguided, because there's no way inside the loop that
'handles' can ever get zeroed.

If I remove this test (3 times) I get all remaining 80 tests to pass.

Also, FreeBSD make has problems with the clean (distclean, etc.) targets:

libtool$ make clean
*** Error code 1
[That's it.]

I traced it down to this:

libtool$ make -dl clean
set -x; set fnord  -d l; amf=$2;  dot_seen=no;  rev=''; list='. libltdl
doc tests'; for subdir in $list; do  rev="$subdir $rev";  test "$subdir" =
"." && dot_seen=yes;  done;  test "$dot_seen" = "no" && rev=". $rev";
target=`echo clean-recursive | sed s/-recursive//`;  for subdir in $rev;
do  echo "Making $target in $subdir";  if test "$subdir" = "."; then
local_target="$target-am";  else  local_target="$target";  fi;  (cd
$subdir && make  $local_target)  || case "$amf" in
*=*) exit 1;; *k*) fail=yes;; *) exit 1;; esac;  done && test -z "$fail"
+ set fnord -d l
+ amf=-d
+ dot_seen=no
+ rev=
+ list=. libltdl doc tests
+ rev=.
+ test . = .
+ dot_seen=yes
+ rev=libltdl .
+ test libltdl = .
+ rev=doc libltdl .
+ test doc = .
+ rev=tests doc libltdl .
+ test tests = .
*** Error code 1

This seems to be a peculiar type of un-optimization on the part of make,
probably splitting the command into two shells.  It might also be a
/bin/sh issue.  (Although I set the shell to bash, make was very
uncooperative about accepting this, so I don't know which shell this is.)
This is really an Automake issue, though, and GNU make works fine.

-- 
Peter Eisentraut   address@hidden   http://funkturm.homeip.net/~peter