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
Message-ID: <3E1DE146.8030901@ece.gatech.edu>
Date: Thu, 09 Jan 2003 15:53:26 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Alexandre Duret-Lutz <duret_g AT lrde DOT epita DOT fr>
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> <2003-01-09-17-11-09+16471+duret_g AT lrde DOT epita DOT fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)

Alexandre Duret-Lutz wrote:

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

Yes.

> 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').

eh, sort of.  If we were still in the days of yore, then you would be 
correct.  However, more modern cygwin and mingw environments (e.g. MSYS) 
provide a patched 'make' that works around the issue.  In fact, foo.exe 
DOES satisfy a 'foo:' rule, but NOT vice versa.  That's why it is okay 
to get foo.exe when building 'foo:' statically, but it *wasn't* okay to 
get foo when building 'foo.exe:' dynamically.

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

Right.  But given the hacked 'make's that are used on cygwin and mingw, 
this solution works "as expected" for both staticly and dynamicly linked 
executables -- on the platforms that these variables (EXEEXT, LT_EXEEXT) 
actually affect.

'Course, there's the whole cross-compiler issue (running on linux, 
building stuff intended for cygwin).

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

Hmmm...now there's a thought.  Perhaps, perhaps...

Said "stub" executable would have to do ALL of the things the script 
does, and then pass that environment to its exec'ed target in .libs/ -- 
does native windows provide an exec() command?  Environment inheritance? 
  You'd probably need different source code for the stub, depending on 
the platform... if buildhost == posixy, then exec() is our friend; 
otherwise, nasty native Windows code...

Unfortunately, I can't work on that right now; my available time just 
went to zero. :-(

--Chuck


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