libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

preparing for 1.5.24


From: Ralf Wildenhues
Subject: preparing for 1.5.24
Date: Sun, 11 Feb 2007 11:24:45 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Hello libtoolers,

I would like to release 1.5.24 as soon as possible.  I've flushed my
queue now, except for the patch I just posted and whatever w32 changes
are still needed.

To ensure that there are no regressions, I would like to announce a sort
of prerelease.  To make things simple, the easiest would be for me to
just wait a day, then tell people on the libtool and maybe also the
autotools-announce lists to download the nightly snapshot and try it.
Would that be ok?  Should we rather do a real prerelease, so it's
archived on alpha.gnu.org, and so the finch.finkproject.org doesn't have
to handle lots of requests (ha ha)?

Any thoughts, comments about this?

FWIW, I've done a test run of branch-1-5, here's some results:

PASS  SKIP  FAIL  config.guess              compiler used   notes
----------------------------------------------------------------------------
 64    29     1   powerpc-ibm-aix4.3.3.0    cc (xlc)        fail: mdemo-inst
 94     0     0   powerpc-ibm-aix4.3.3.0    cc (xlc)        rtl
 70    32     1   powerpc-ibm-aix5.1.0.0    cc (xlc), xlC_r fail: mdemo-inst
103     0     0   powerpc-ibm-aix5.1.0.0    cc (xlc), xlC_r rtl
 70    32     1   powerpc-ibm-aix5.2.0.0    cc (xlc), xlC_r fail: mdemo-inst
103     0     0   powerpc-ibm-aix5.2.0.0    cc (xlc), xlC_r rtl
 70    32     1   powerpc-ibm-aix5.3.0.0    cc (xlc), xlC_r fail: mdemo-inst
103     0     0   powerpc-ibm-aix5.3.0.0    cc (xlc), xlC_r rtl
110     1     1   i686-pc-cygwin            gcc, g++, g77   fail: mdemo2-make
103     0     0   powerpc-apple-darwin8.7.0 gcc, g++
112     0     0   i386-unknown-freebsd6.2   gcc, g++, g77
 83    11     0   hppa2.0-hp-hpux10.20      cc              skip: 
demo-nofast/depdemo-nofast and f'ups, demo-nopic
 92    11     0   hppa2.0w-hp-hpux11.00     cc, aCC         likewise
 92    11     0   hppa2.0w-hp-hpux11.11     cc, aCC         likewise 
 92    11     0   hppa2.0w-hp-hpux11.23     cc, aCC         likewise
102     0     1   ia64-hp-hpux11.23         cc, aCC,        fail: hardcode
100     0     3   mips-sgi-irix6.5          cc, CC,         fail: hardcode, 
build-relink2, link-order
111     1     0   x86_64-unknown-linux-gnu  gcc, g++, g77   skip: demo-nopic
109     1     2   i686-pc-mingw32           gcc, g++, g77   fail: dryrun, 
mdemo-make
110     0     2   i386-unknown-openbsd3.9   gcc, g++, g77   fail: hardcode, 
link-order
103     0     0   alphaev5-dec-osf4.0d      cc, cxx
103     0     0   alphaev67-dec-osf5.1      cc, cxx
101     1     1   sparc-sun-solaris2.6      cc, CC          fail: hardcode, 
skip: demo-nopic, needs gmake
110     1     1   sparc-sun-solaris2.7      cc, CC, f77     fail: hardcode, 
skip: demo-nopic
111     1     0   sparc-sun-solaris2.8      cc, CC, f77     skip: demo-nopic
111     1     0   sparc-sun-solaris2.9      likewise
111     1     0   sparc-sun-solaris2.10     cc, CC, f77     skip: demo-nopic
111     1     0   i386-pc-solaris2.10       cc, CC, f90     skip: demo-nopic

Notes:
- The mdemo failures on AIX without runtimelinking are well known.  HEAD
  does better here.  I am reluctant to backport, though, and propose to
  leave things as they are.
- The hardcode failures are at least partly due to the weird test.
  I think writing more better tests in HEAD (additionally to shlibpath.at)
  can help sort things out here.  I propose leaving things here as well.
- OpenBSD: The link-order failure is fixed in HEAD with the introduction
  of hardcode_direct_absolute.  I do not want to backport.
- The IRIX failures are not new.  Looking into a fix though.
- It would help me greatly if someone could look into the Cygwin and
  MinGW mdemo* failures; and documentation updates if needed.

To conclude, I think we're in shape unless we learn about important bugs
in the release candidate.  Of course a much better test exposure would
be good (e.g., GCC on many of the above systems).

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]