Mail Archives: cygwin/2002/05/12/22:49:14
I've uploaded test versions of:
autoconf-devel-2.53a-1
automake-devel-1.6.1-3
libtool-devel-20020502-2
autoconf: updated to official '2.53a' release. Previous cygwin version
was 2.53.
automake: updated to official '1.6.1' release. Previous cygwin version
was 1.6. Also added a few fixes.
libtool: updated to official CVS from 2002-05-02. Previous cygwin
version was based on official CVS from 2002-03-16. Also added some
fixes that have been discussed on this list.
Ralf, Robert, Corinna, other interested parties, please give these a
good workout. Notes on test results and my comments below.
Note that you need to follow the standard procedure with setup.exe to
install these 'test' versions.
--Chuck
TEST RESULTS -- AUTOCONF:
## ------------------------------------------ ##
## All 163 tests were successful (3 skipped). ##
## ------------------------------------------ ##
TEST RESULTS -- AUTOMAKE:
As previously reported on this list, there were two unexpected failures:
pr300-ltlib
subobj9
The first one is due to a libtool bug (two copies of each .o are
included in static archives -- which doubles their size, but also makes
'strip --strip-debug' go nuts.) The second is due to the 'cp -p' bug
that I've been trying to fix. But, in each case, the problem is not in
automake...
TEST RESULTS -- LIBTOOL:
failed the following tests:
dry-run
mdemo-inst[mdemo-conf] (foo1.dll not found win32 popup)
hardcode
build-relink2 (***.dll not found win32 popups)
mdemo-inst[mdemo-shared] (foo1.dll not found win32 popup)
quote
dry-run: dunno, this used to work. A bug was introduced into HEAD CVS
sometime between 2002-03-16 and 2002-05-02. I haven't had a chance to
track this one down.
the two mdemo-inst failures: modules are not installed in the PATH, nor
are they in the same directory as the test executable. So, the test
fails because Windows can't find the module DLL. If the PATH is set
properly, the test succeeds. So, two choices for modules: (1) we
mandate that module DLLs go into /bin, or (2) we mandate that folks add
"my-module-directory" to PATH. I favor the latter -- which means that
this test failure isn't really a "failure". However, perhaps the test
should create wrapper scripts to set the PATH appropriately before
calling the test executable...
hardcode: we always fail this one.
build-relink2. I fixed one bug, but another showed up: $PATH doesn't
get set properly when running this test...This test
used to get skipped on cygwin, but no longer?
quote:
compile mode seems okay
install mode seems okay
link mode *always* fails -- like this:
"failed: mkdir .libs
gcc -o hell.exe -g -O -Wl,-someflag=test foo.o"
?? *mkdir* fails??
But it works fine in compile mode---
"passed: mkdir .libs
gcc -c "-DVAR= test " foo.c -DPIC -o .libs/foo.o
gcc -c "-DVAR= test " foo.c -o foo.o >/dev/null 2>&1"
Dunno about this one...but we've always failed it in the past, so this
isn't a regression.
OTHER NOTES ABOUT LIBTOOL
1) to force static linking of executables, you need to have -all-static
as a libtool link flag. If you merely use '-static', then libtool
'eats' its, gcc never sees it, and you get a dynamically linked executable.
2) build-relink: we expect to fail this operations (which is a PASS of
this test) -- but the failure mode is a windows popup that requires
manual intervention. We used to skip this test on cygwin; I'm not sure
why we don't skip it now. We probably should skip it.
3) For all tags, (and host=cygwin) set allow_undefined_flag="" so that
the --auto-import magic works properly. For all tags (and host=cygiwn)
set always_export_symbols=no -- it is unnecessary thanks to binutils'
auto-export magic.
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -