Re: [Mingw-users] Re: Solving the relink exe's libtool problem[take 2]

2003-01-12 Thread Earnie Boyd
Charles Wilson wrote: There are two places in ltmain.sh where the shell wrapper is directly sourced. This doesn't work very well, because when both foo and foo.exe exist, . ./foo ends up sourcing foo.exe -- which is bad. This can be resolved by ``. ./foo.'' instead for the cygwin/mingw

Re: [Mingw-users] Re: Solving the relink exe's libtool problem[take 2]

2003-01-12 Thread Charles Wilson
Earnie Boyd wrote: Charles Wilson wrote: There are two places in ltmain.sh where the shell wrapper is directly sourced. This doesn't work very well, because when both foo and foo.exe exist, . ./foo ends up sourcing foo.exe -- which is bad. This can be resolved by ``. ./foo.'' instead for

Re: Solving the relink exe's libtool problem [take 2]

2003-01-12 Thread Charles Wilson
Alexandre Duret-Lutz wrote: Any way lt-foo.c could go into .libs/? Or just be erased after foo.exe has been built? Maybe both? I see no problems with either or both...but I'd rather keep lt-foo.c around until 'make clean' (or libtool --mode=clean) time. Also I if you don't move `foo' to

Re: Solving the relink exe's libtool problem [take 2]

2003-01-11 Thread Charles Wilson
Alexandre Duret-Lutz wrote: Chuck Said stub executable would have to do ALL of the Chuck things the script does, and then pass that environment Chuck to its exec'ed target in .libs/ -- Maybe it could just exec() something like `/bin/sh .libs/foo.sh', where `.libs/foo.sh' is the script