This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[ANNOUNCEMENT] Updated: libtool-devel-1.5-3 [Requires cygwin-1.5.3+]


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:

------------------------
<top-sourcedir>/Makefile.in
<top-sourcedir>/foo/foo.c
<top-sourcedir>/sharedlib/<library files, own Makefile.in>
------------------------

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]