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: <3DD3F7B5.6060006@ece.gatech.edu>
Date: Thu, 14 Nov 2002 14:21:25 -0500
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
Subject: [avail for test] libtool-devel-20021111-1
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I've put an updated version of libtool-devel on sourceware, available as 
a test package.  It is based on libtool CVS from 2002-11-11, plus an 
additional set of patches to work around issues with gcc-3's runtime 
libraries (the dreaded "libstdc++.la" issue).

Note that libtool-devel-20021111 depends on autoconf-devel-2.54 or 
newer, and automake-devel-1.7.1 or newer.

Changes from 20020705-1
o updated to 20021111 CVS
   - fixed the "static archives contain duplicate .o's" program
     http://mail.gnu.org/pipermail/libtool/2002-July/006500.html
   - fixed the issue where libtool improperly concludes that cygwin's
     gcc cannot support -c and -o in the same command
   - includes some bugfixes in libltdl (considered "Showstoppers" by
     the Guile team)
   - DESIGN DECISION: (this is a a change from previous behavior)
     libtool will refuse to create a shared library if any of its
     dependencies are available only as static archives.  DLLs may
     only depend on other DLLs (*)
o corrects the 'make install DESTDIR=' issue with interdependent
   shared libraries
o correctly identifies import libraries as "shared objects", so that
   libtool's new "DLLs may only depend on other DLLs" behavior isn't
   triggered with fatal results when a target DLL's dependencies are
   satisfied by import libs. (**)
o Skips the "DLLs may only depend on other DLLs" check when the
   dependency is one of the "standard" runtime libs which are currently
   available only in static form (libgcc.a, libstdc++.a, etc) on
   cygwin/mingw.
o Isn't "confused" by the libtool .la files supplied with cygwin's gcc,
   even though they only specify static archives  (e.g. libstdc++.la
   lists "libstdc++.a" but not "cygstdc++.dll" [which is good because
   cygstdc++.dll doesn't exist]).
o No longer records compiler builtin library paths or compiler-generated
   deplibs (like -luser32 -lgcc) in the "dependency_libs" variable in
   generated .la files.  (***)

(*) This is a good idea.  But, we need workarounds for the standard 
runtime libs like libgcc.a, libstdc++.a, etc.  These workarounds are 
implemented in this libtool test release.

(**) this is implemented via a new shell function 'win32_libid'.  As 
Ralf has pointed out, win32_libid is slow, and can be accelerated in 
future versions, depending on the shortcuts we take (balancing pedantic 
correctness vs. speed).  This version is (relatively) slow, but correct 
in all(?) cases.

(***) e.g. if cygwin's gcc-3.2 had been built with this version of 
libtool, then /usr/lib/libstdc++.la wouldn't be so "weird".  But, don't 
bug cgf about this; there are a LOT of changes necessary in the gcc 
codebase before that will ever be possible.  The gcc team needs to 
update to more recent versions of autoconf and automake throughout, stop 
hand-editing aclocal.m4 (e.g. put unique code into acinclude.m4 instead, 
and use aclocal to regen aclocal.m4 on the fly), etc.  Then, and only 
then, could the gcc team use a modern version of libtool...Some work 
toward that end is occuring; check the binutils and gcc mailing lists 
for more info.

Unresolved issues: relinks .exe files over and over and over (e.g. every 
time 'make' is called, even if the .exe has already been built.  This is 
a longstanding libtool bug (e.g. it's not a regression).

See NOTES below.

--
Chuck

To update your installation, click on the "Install Cygwin now" link
on the http://cygwin.com/ web page.  This downloads setup.exe to
your system.  Save it and run setup, answer the questions and pick
up 'libtool-devel' from the 'Devel' category.  Because this is an 
experimental 'test' release, you must click on the 'Exp' radio button in 
order for the 20021111-1 version of libtool-devel to show up, or click 
on the spinner (version number) until 20021111-1 is displayed.

Note that downloads from sources.redhat.com (aka cygwin.com) aren't
allowed due to bandwidth limitations.  This means that you will need
to find a mirror which has this update.

In the US, ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/
is a reliable high bandwidth connection.

In Japan, ftp://ftp.u-aizu.ac.jp/pub/gnu/gnu-win32/ is already
updated.

In DK, http://mirrors.sunsite.dk/cygwin/ is usually up-to-date.

If one of the above doesn't have the latest version of this package
you can either wait for the site to be updated or find another
mirror.

Please  send questions or comments to the Cygwin mailing list at:
cygwin AT sources DOT redhat DOT com .  If you want to subscribe go to:
http://cygwin.com/lists.html I would appreciate if you would use
this mailing list rather than emailing me directly.  This includes
ideas and comments about the setup utility or Cygwin in general.

If you want to make a point or ask a question the Cygwin mailing
list is the appropriate place.

                 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

To unsubscribe to the cygwin-announce mailing list, look at the
"List-Unsubscribe: " tag in the email header of this message. Send
email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-YOU=YOURDOMAIN DOT COM AT cygwin DOT com

NOTES:

Two selftest failures (longstanding, not regressions)

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"


--
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/