Mailing-List: contact cygwin-announce-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-announce-owner AT cygwin DOT com Delivered-To: mailing list cygwin-announce AT cygwin DOT com Delivered-To: moderator for cygwin-announce AT cygwin DOT com Message-ID: <3E0DDCB1.40901@ece.gatech.edu> Date: Sat, 28 Dec 2002 12:17:37 -0500 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cygwin-announce AT cygwin DOT com Subject: Updated: libtool-devel-20021227, libltdl3-20021227-1 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit libtool-devel has been updated to the 20021227 CVS codebase, as well as libltdl3. A few additional modifications of my own are also included that haven't yet made it into CVS HEAD. Note that libtool-devel-20021227 depends on autoconf-2.55 or newer (currently, the only cygwin official release of autoconf that satisfies this is autoconf-devel-2.57-1), and automake-1.7.1 or newer (either automake-devel-1.7.1-1 or automake-devel-1.7.2-1 will work). Changes from 20021111-1 o updated to 20021227 CVS - all of the previous changes in 20021111-1 have been accepted into libtool CVS HEAD (and are therefore present in 20021227) o -export-symbols now works properly (it's been broken for over two years...) 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). ==IMPORTANT== 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: Important notes from 20021111: o DESIGN DECISION: (this is a a change from pre-20021111 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 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 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. ===================================================================== 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"