Mail Archives: cygwin-announce/2002/05/19/17:58:02
The 'libtool-devel' package has been updated to 20020502-2
It contains a (slightly) hacked version of libtool (from
CVS 02-May-2002), installed into /usr/autotool/devel/*.
Most of our earlier changes have been absorbed into the
official libtool CVS. However, this version contains some
new fixes based on feedback from the cygwin list. Hopefully
those changes will soon be accepted into official libtool
CVS soon.
See the NOTES at the end of this email for some additional
information, and recent 'make check' results.
--
Chuck Wilson
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. You may need to
click the "Full" button if it doesn't show up.
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
Contents:
TEST RESULTS:
OTHER NOTES ABOUT LIBTOOL
GENERAL NOTES:
-----------------------------------
TEST RESULTS:
-----------------------------------
failed the following tests:
dry-run
mdemo-inst[mdemo-conf] (foo1.dll not found win32 popup)
hardcode
build-relink2 (***.dll not found win32 popups)
mdemo-inst[mdemo-shared] (foo1.dll not found win32 popup)
quote
dry-run: dunno, this used to work. A bug was introduced into HEAD CVS
sometime between 2002-03-16 and 2002-05-02. I haven't had a chance to
track this one down.
the two mdemo-inst failures: modules are not installed in the PATH, nor
are they in the same directory as the test executable. So, the test
fails because Windows can't find the module DLL. If the PATH is set
properly, the test succeeds. So, two choices for modules: (1) we
mandate that module DLLs go into /bin, or (2) we mandate that folks add
"my-module-directory" to PATH. I favor the latter -- which means that
this test failure isn't really a "failure". However, perhaps the test
should create wrapper scripts to set the PATH appropriately before
calling the test executable...
hardcode: we always fail this one.
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"
Dunno about this one...but we've always failed it in the past, so this
isn't a regression.
-----------------------------------
OTHER NOTES ABOUT LIBTOOL
-----------------------------------
1) to force static linking of executables, you need to have -all-static
as a libtool link flag. If you merely use '-static', then libtool
'eats' its, gcc never sees it, and you get a dynamically linked executable.
2) build-relink: we expect to fail this operations (which is a PASS of
this test) -- but the failure mode is a windows popup that requires
manual intervention. We used to skip this test on cygwin; I'm not sure
why we don't skip it now. We probably should skip it.
3) For all tags, (and host=cygwin) set allow_undefined_flag="" so that
the --auto-import magic works properly. For all tags (and host=cygiwn)
set always_export_symbols=no -- it is unnecessary thanks to binutils'
auto-export magic.
-----------------------------------
GENERAL NOTES:
-----------------------------------
1) libtool (along with autoconf and automake) are really only for
developer use. If you don't already have a good understanding of
how to use the tools -- and experience using them on a "normal"
unix platform -- then you probably DON'T want to "learn" with this
port. The combination of
a) the brain dead DLL format (compared to elf shared libs)
b) still evolving shared lib support in the binutils/gcc/cygwin
c) the VERY beta status of libtool-devel
d) the wacky -stable/-devel/wrapper structure we are forced to
use
means that cygwin is NOT a good platform to "learn how to use
the autotools". PLEASE do not ask for tutorials on
automake/autoconf/libtool use on the cygwin mailing list -- you will
either be ignored, or mocked.
2) ALL libtools since version 1.4 (May 2001) have dispensed with
ltconfig.sh. So, when re-libtoolizing, be sure to delete ltconfig.sh
first.
3) You can't "pick and choose". If you want to use libtool-devel, you
must also use automake-devel and autoconf-devel. Likewise, all of the
-stable versions must be used together.
4) libtool-devel installs its info files and man pages into /usr/* as
well as into /usr/autotool/devel/*. Also, libtool-devel's cygltdl-3.dll
is installed into /usr/bin. Therefore, applications dynamically linked
to that DLL by libtool-stable and by libtool-devel will both use
libtool-devel's version at runtime. (Fortunately, this is okay --
libtool-devel's cygltdl-3.dll works fine with apps that expect
libtool-stable's version).
- Raw text -