This is the mail archive of the
mailing list for the Cygwin project.
Re: [ITP] util-linux
On Fri, Mar 03, 2006 at 10:15:54AM +0100, Corinna Vinschen wrote:
> On Mar 2 20:13, Eric Blake wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > According to Yaakov S (Cygwin Ports) on 3/2/2006 3:06 PM:
> > >>> No. With Corinna's patch to add CYGWIN=transparent_exe option, we are
> > >>> asking for problems if we distribute a script alongside an exe.
> > >
> > > OK, but I can think of one *major* "violation" of this: libtool-built
> > > applications, when linking against a to-be-installed library in the same
> > > package. In such a case, the real .exe is placed in .libs, and both an
> > > extension-less libtool script and a launcher .exe are placed in the
> > > builddir; this allows one to run the application w/o installing it.
> > Yes, I'm aware of that, and I would love to spend some free time trying to
> > solve another way for libtool to work without relying on the (subtle)
> > difference between 'foo' and 'foo.exe' when testing uninstalled
> > libtoolized applications. This libtool (ab)use of filenames has already
> > had difficulties with managed mounts and trailing dots. Then there was
> > the time when I tried to patch rm in coreutils-5.3.0 to handle .exe
> > transparently (and immediately had to retract that change because of libtool).
> I'm all on your side Eric. I don't understand why this libtool behaviour
> is necessary at all. There must be really another way without having
> foo and foo.exe in the same directory. "This works fine on Linux without
> this hack"(TM).
> Charles? Any chance that libtool could do without this hack?
The foo.exe wrapper is really silly, it just looks for a script named foo and
does execv on it (using $SHELL and the args passed to the foo.exe).
I think the main reason it's there is for make rules etc etc that expect $EXEEXT
to be ".exe" on Cygwin, which brings a bunch of undesireable behaviour if no
foo.exe is created.
With transparent_exe, I'd argue that $EXEEXT should be "". Fix that first, then
I think the stupid foo.exe wrapper can be zapped for Cygwin. I haven't really
digged into the problem though, so surprises might crop up...