From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6793 invoked by alias); 5 Sep 2003 05:45:20 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 6741 invoked from network); 5 Sep 2003 05:45:18 -0000 Received: from unknown (HELO redhat.com) (24.131.133.249) by sources.redhat.com with SMTP; 5 Sep 2003 05:45:18 -0000 Received: by redhat.com (Postfix, from userid 201) id 5B81532A822; Fri, 5 Sep 2003 01:45:16 -0400 (EDT) From: Charles Wilson To: cygwin@cygwin.com Subject: [ANNOUNCEMENT] Updated: libtool-devel-1.5-3 [Requires cygwin-1.5.3+] Reply-To: cygwin@cygwin.com Message-Id: <20030905054516.5B81532A822@redhat.com> Date: Fri, 05 Sep 2003 05:45:00 -0000 X-SW-Source: 2003-09/txt/msg00352.txt.bz2 The libtool-devel package contains the 1.5 version of libtool, a cross-platform tool for building libraries (shared and otherwise). It enables relatively trouble-free builds of DLLs on cygwin and mingw. This release is built against the cygwin-1.5.x kernel; it will not work with 1.3.22. (Yes, I know that libtool is mostly a big shell script. But it also includes the dynamic loader library, cygltdl-3.dll.) CHANGES: * compiled against cygwin-1.5.2 kernel * Documentation moved to /usr/share/* * includes some patches from libtool-CVS: - Max Bowser's library search order fix - a fix for tests/dryrun. * bugfix for wrapper executable when wrapper is invoked via ${PATH}. Submitted to libtool cvs. See NOTES below for older news, and selftest results. -- Charles Wilson libtool-devel volunteer maintainer for cygwin 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. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from 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.com@cygwin.com If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at the above URL. NOTES: ------------------------- KNOWN ISSUES: ================================================================== 1) Building an executable, that links against a shared library that is part of the same package, where the source file(s) are in a different subdir than the makefile that builds the executable, doesn't work. (yeah, real "common" case. Known to affect expat) Example: ------------------------ /Makefile.in /foo/foo.c /sharedlib/ ------------------------ /Makefile.in contents: ... default: buildlib foo/foo buildlib: $(LIBRARY) all: $(LIBRARY) foo/foo ----------------------- For more info, see http://www.cygwin.com/ml/cygwin/2003-04/msg01247.html ----------------------------------------------------------------- 2) Open issue: pseudo-cross compiler setup doesn't work (e.g. setting CC='gcc -mno-cygwin' and expecting a mingw output doesn't work, although it's unclear whether it SHOULD work, even if at some point in the past it did.) The binary wrapper program hardcodes "/bin/sh" -- which is not a valid pathname for a -mno-cygwin program. It'd be best to compile the wrapper with plain "gcc" -- But without making a distincution between the buildplatform compiler and the hostplatform compiler (e.g. without using --build= --host=), we can't know about the need for this distinction. IMO, fixing the "relink .exe ad nauseum" problem is more important than this corner case -- and there are other ways of addressing this corner case, which do not involve changes to libtool. NEW FEATURES: ================================================================== o adds partial support for including .rc files and using windres to add resources to executables and libraries. You still must add something like the following to your Makefile.am file: LTRCCOMPILE = $(LIBTOOL) --mode=compile $(RC) \ `echo $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) |\ sed -e 's/-I/--include-dir /g;s/-D/--define /g'` and then explicitly include a build rule: %.o : %.rc $(LTRCCOMPILE) -i $@ -o @^ 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 (*) (*) 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. 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. (**) (**) 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" -- even though cgf removed it entirely from the more recent releases of gcc-3.2 for cygwin. However, if you've got an old version of cygwin-gcc-3.2, this libtool won't croak. SELFTEST FAILURES ===================================================================== Three selftest failures (two longstanding, not regressions; one recent due to changes [bug?] in cygwin1.dll) 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 Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/