Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/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
To: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
Cc: cygwin AT cygwin DOT com, libtool-patches AT gnu DOT org, automake-patches AT gnu DOT org,
   mingw-users AT lists DOT sourceforge DOT net
Subject: Re: Solving the "relink exe's" libtool problem
References: <3E19C657 DOT 1040904 AT ece DOT gatech DOT edu>
From: Alexandre Duret-Lutz <duret_g AT lrde DOT epita DOT fr>
X-Home-Page: http://gadl.free.fr/
X-GPG-Keyserver: http://pgp.mit.edu/
X-GPG-Fingerprint: FCA0 8615 0211 941A 2AB9  FA66 3859 C03B 2E23 6E47
Date: Thu, 09 Jan 2003 17:11:09 +0100
In-Reply-To: <3E19C657.1040904@ece.gatech.edu> (Charles Wilson's message of
 "Mon, 06 Jan 2003 13:09:27 -0500")
Lines: 42
User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2
 (i386-debian-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <2003-01-09-17-11-09+16471+duret_g@lrde.epita.fr>
X-Attribution: adl

>>> "Chuck" == Charles Wilson <cwilson AT ece DOT gatech DOT edu> writes:

 Chuck> There has been a long-standing problem with libtool on windows-ish
 Chuck> platforms (cygwin, mingw, others?), in which libtool relinks exe's
 Chuck> over and over and over, when the exe depends on a shared lib that is
 Chuck> also built as part of the same package.

 Chuck> This behavior is due to the necessity that we must use a wrapper
 Chuck> script to set the PATH properly, so that the newly compiled exe can
 Chuck> "find" its shared lib, when run "in place" -- e.g. as part of a
 Chuck> test-suite.  Thus, we have

 Chuck> <build-dir>/foo             (wrapper script)
 Chuck> <build-dir>/.libs/foo.exe   (real exe)

 Chuck> However, the Makefile target is "foo$(EXEEXT)" -- which
 Chuck> isn't satisfied by the "foo" wrapper script, so 'make'
 Chuck> keeps trying to create it. 

Maybe I'm wrong, but my understanding is that wrapper scripts
are generated only when linking programs with uninstalled shared
libraries.

For instance wrapper scripts aren't created when the user uses
--disable-shared, or simply if some program in the package
doesn't link with shared libraries.  In these cases reseting
EXEEXT globally doesn't look like a solution (I guess it would
just create the converse issue: the `foo:' target not satisfied
by `foo.exe').

In the current situation I don't think there is any way to find
out whether a Makefile target needs `.exe' appended.

 Chuck> However, the wrapper script can NOT be named "foo.exe",
 Chuck> for a number of good reasons.

I assume these reasons are related to the word `script'?
Have binaries been considered?

[...]
-- 
Alexandre Duret-Lutz


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/