Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <3CDF29A7.3040600@ece.gatech.edu>
Date: Sun, 12 May 2002 22:49:11 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
CC: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>,
   Ralf Habacker <Ralf DOT Habacker AT freenet DOT de>
Subject: test -devel versions of the autotools
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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/