X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <47FBF68C.6070709@users.sourceforge.net>
Date: Tue, 08 Apr 2008 17:49:48 -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: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
References: <47F6A816 DOT 2010208 AT alice DOT it> <47F73BA6 DOT 6000001 AT alice DOT it> <47F7E1D1 DOT 804DF919 AT dessent DOT net> <47F94F88 DOT 6050705 AT cwilson DOT fastmail DOT fm> <47F9A114 DOT 3060608 AT users DOT sourceforge DOT net> <47F9B6B6 DOT 4090908 AT cwilson DOT fastmail DOT fm> <47FA254B DOT 205 AT users DOT sourceforge DOT net> <47FB0E98 DOT 3060402 AT cwilson DOT fastmail DOT fm> <47FB25D3 DOT 6040703 AT users DOT sourceforge DOT net> <47FB83D4 DOT 5080600 AT cwilson DOT fastmail DOT fm>
In-Reply-To: <47FB83D4.5080600@cwilson.fastmail.fm>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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

Charles Wilson wrote:
| I'm not so sure. I still think that calling LT_OUTPUT immediately after
| LT_INIT is not exactly equivalent to 1.5 behavior. I think that is too
| early...but I don't know how to force a non-local insertion of
| LT_OUTPUT, and even if I did, I don't know how "far down" in
| configure.ac that non-local insertion should go.

I think it is equivalent, seeing from a typical configure run with
libtool 1.5:

...
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
configure: creating libtool
appending configuration tag "CXX" to libtool
...
appending configuration tag "F77" to libtool
...

| Of course, if you KNOW of a package that needs libtool before configure
| is finished (I don't), you could easily test my assertion by manually
| inserting LT_OUTPUT immediately after A[CM]_PROG_LIBTOOL/LT_INIT,
| manually running autoreconf with libtool2.2, and see if it works...

Some GNOME autoconf-based packages with python support run a
python-module compile and link test with the previously created libtool.

| That's a drawback, all right.

Looking at some of the other compatibility macros, how about the
following instead:

AU_DEFUN([AC_PROG_LIBTOOL],
[LT_INIT
LT_OUTPUT
AC_DIAGNOSE([obsolete],
[$0: Remove this warning and the call to LT_OUTPUT if you do not need
libtool to exist before AC_OUTPUT.])
])

AU_ALIAS([AM_PROG_LIBTOOL], [AC_PROG_LIBTOOL])

| But even so, this means that as part of cygport [*] you'd need to run
| autoupdate, which is not the current behavior.
|
| [*] But again, my recommedation is that cygport should NOT run
| autoupdate in an automated way. Instead, the package maintainer should
| run it, inspect the results, and fold those changes into .src.patch.  In
| which case, manually adding LT_OUTPUT before generating .src.patch only
| when necessary rather than relying on autoupdate to do it automatically
| always even when unecessary, seems to be the better way to go.

Agreed.

| Correct. The gcc folks ran into this. FWICT, you need each of:
| libtool.m4, ltoptions.m4, ltsugar.m4, ltversion.m4, lt-obsolete.m4,
|
| It is recommeded, instead of copying those contents into aclocal.m4,
| that instead you do:
|
| m4_include([libtool.m4])
| m4_include([ltoptions.m4])
| m4_include([ltversion.m4])
| m4_include([ltsugar.m4])
| m4_include([lt~obsolete.m4])

While that makes sense, I doubt that would work with the special build
systems that I'm discussing, at least not in an automated way without
patching those build systems more than necessary.  I have something else
in mind, but I'll need to try it out first.

| Sure...just waiting for more input.

Could you post the answer on cygwin-apps?

| I have modified cygport's setup.hint on sources.

Thank you.


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

iD8DBQFH+/aMpiWmPGlmQSMRCLeqAJ42Na5Iyxr2C3Bzs7vnuVWinav3uQCgxWgw
K4mhjGWMeBAM1R92B3LsJQU=
=FHgr
-----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/