X-Recipient:	archive-cygwin AT delorie DOT com
X-Spam-Check-By:	sourceware.org
Message-ID:	<48110B6B.2050904@users.sourceforge.net>
Date:	Thu, 24 Apr 2008 17:36:27 -0500
From:	"Yaakov (Cygwin Ports)" <yselkowitz AT users DOT sourceforge DOT net>
User-Agent:	Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
References:	<announce DOT 48038853 DOT 7090707 AT cwilson DOT fastmail DOT fm>
In-Reply-To:	<announce.48038853.7090707@cwilson.fastmail.fm>
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Chuck,

Here's yet another interesting case with libtool-2.2:

/bin/sh ../../libtool --tag=CXX --mode=link g++  -O2 -pipe    -o
libfoo-1.2.la -rpath /usr/lib -no-undefined sources.lo
libtool: link: rm -fr  .libs/libfoo-1.2.dll.a .libs/libfoo-1.2.la
.libs/libfoo-1.2.lai
libtool: link: g++ -shared -nostdlib   .libs/sources.o
- -L/usr/lib/gcc/i686-pc-cygwin/3.4.4
- -L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. -lstdc++ -lgcc -lcygwin
- -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc     -o
.libs/cygfoo-1.2-0.dll -Wl,--enable-auto-image-base -Xlinker
- --out-implib -Xlinker .libs/libfoo-1.2.dll.a
Creating library file: .libs/libfoo-1.2.dll.a
libtool: link: ar cru .libs/libfoo-1.2.  sources.o
libtool: link: ranlib .libs/libfoo-1.2.
libtool: link: ( cd ".libs" && rm -f "libfoo-1.2.la" && ln -s
"../libfoo-1.2.la" "libfoo-1.2.la" )

In this specific case, the static library is missing the ".a" extension
(Windows ignores the final dot, as usual).  Here's why:

This package had AM_GNU_GETTEXT in configure.ac without any arguments
nor AM_GNU_GETTEXT_VERSION.  autoreconf decided "not using Gettext"[1]
and didn't install config.rpath[2].  But AC_LIB_RPATH (from the included
gettext-0.11.2 lib-link.m4) was called; while nothing happened due to
the missing config.rpath, it then defined libext=$acl_cv_libext, which
had never been defined.  This empty $libext clobbered that of libtool.

In this case, the solution was simply to call AM_GNU_GETTEXT_VERSION.
But this is the second case where libtool's had its variables clobbered
by other parts of configure.  Could something be done to make sure that
that can't happen?


Yaakov


[1] autoreconf decided "not using Gettext" because it looks solely for
AM_GNU_GETTEXT_VERSION to make that determination.  (It only looks for
AM_GNU_GETTEXT to see if one of these two is used without the other, and
emits a warning if so.)

[2] lib-link.m4 0.15 adds a line telling automake >= 1.10 that
config.rpath is required, but this package was using 1.9.  In any case,
this macro was from 0.11.2, which preceded automake-1.10.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkgRC2sACgkQpiWmPGlmQSPDkwCfdkU3rN1Ul1YYm6yhebClVyDg
Eu0AoO+O803peOIDxLD4RFEKNIWRHvyi
=mGuQ
-----END PGP SIGNATURE-----

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

- Raw text -