This is the mail archive of the cygwin-announce@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]

Updated: libtool-devel-1.5, libltdl3-1


libtool-devel has been updated to the 1.5 release, as well as libltdl3.

At long last, the super spiffy auto-import-based, mostly "just like unix" DLL support for cygwin is available in the official, stable, libtool release. Now is the time to start bugging your favorite upstream maintainers to update their packages to the latest autotools -- and in most cases, they'll get cygwin and mingw DLLs for free.

Note that libtool-devel-1.5 depends on autoconf-devel-2.57 or newer, and automake-devel-1.7.3 or newer.

Changes from 20020216-1

o updated to the official 1.5 release

==IMPORTANT==
see NOTES below, for NEW FEATURES, KNOWN ISSUES, and SELFTEST FAILURES.

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

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

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 -export-symbols <a def file> now works properly (it's been broken
  for over two years...)

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)

dryrun:
-------------------
It seems there is a race condition with regards to 'ls -l' computing the total size of all files in a directory. This cause the "before" snapshot to be incorrect -- while the "after" snapshot is correct. And during a dryrun test, "before" should equal "after" -- and they don't. but not because the file-on-disk are different; that "before" snapshot of those files-on-disk is simply wrong. I'm pretty sure this isn't a libtool bug...and it won't affect actual libtool --mode=dry-run operation.


http://www.cygwin.com/ml/cygwin/2003-04/msg01476.html

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"


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