automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Solving the "relink exe's" libtool problem


From: Charles Wilson
Subject: Re: Solving the "relink exe's" libtool problem
Date: Thu, 09 Jan 2003 15:53:26 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]