[Top][All Lists]
[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
- Solving the "relink exe's" libtool problem, Charles Wilson, 2003/01/07
- Re: Solving the "relink exe's" libtool problem, Alexandre Duret-Lutz, 2003/01/09
- Re: Solving the "relink exe's" libtool problem,
Charles Wilson <=
- Re: [Mingw-users] Re: Solving the "relink exe's" libtool problem, Earnie Boyd, 2003/01/09
- Re: Solving the "relink exe's" libtool problem, Alexandre Duret-Lutz, 2003/01/09
- Re: Solving the "relink exe's" libtool problem [take 2], Charles Wilson, 2003/01/11
- Re: [Mingw-users] Re: Solving the "relink exe's" libtool problem [take 2], Earnie Boyd, 2003/01/12
- Re: [Mingw-users] Re: Solving the "relink exe's" libtool problem [take 2], Charles Wilson, 2003/01/12
- Re: Solving the "relink exe's" libtool problem [take 2], Alexandre Duret-Lutz, 2003/01/12
- Re: Solving the "relink exe's" libtool problem [take 2], Charles Wilson, 2003/01/12
- Re: Solving the "relink exe's" libtool problem [take 3], Charles Wilson, 2003/01/13
- Re: [Mingw-users] Re: Solving the "relink exe's" libtool problem [take 3], Earnie Boyd, 2003/01/20
- Re: [Mingw-users] Re: Solving the "relink exe's" libtool problem[take 3], Bruce Korb, 2003/01/20