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: <3CE81DC8.90409@ece.gatech.edu> Date: Sun, 19 May 2002 17:48:56 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: cygwin-announce AT cygwin DOT com Subject: Updated: libtool-devel-20020502-2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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).