[ITP] util-linux

[Peter Ekberg]

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

But.

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.

But.

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

Cheers,
Peter