Message-ID: <440A3ADD.1040900@byu.net>
Date: Sat, 04 Mar 2006 18:11:57 -0700
From: Eric Blake <ebb9 AT byu DOT net>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com, bug-libtool AT gnu DOT org
Subject: libtool vs. transparent_exe [Was: [ITP] util-linux]
References: <4404D661 DOT 5040608 AT users DOT sourceforge DOT net> <4405A032 DOT 4000800 AT byu DOT net> <44076C6D DOT 3050706 AT users DOT sourceforge DOT net> <4407B43D DOT 2070505 AT byu DOT net> <4408CE3A DOT 5060709 AT cwilson DOT fastmail DOT fm>
In-Reply-To: <4408CE3A.5060709@cwilson.fastmail.fm>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[moving to cygwin list instead of cygwin-apps, and cross-posting to
bug-libtool]

[Background for bug-libtool - cygwin recently introduced an optional
setting, called transparent_exe, that makes it impossible for "foo" and
"foo.exe" to coexist in a non-managed mount.  When this option is in
effect, a Windows disk file named foo.exe is presented to stat() and
readdir() as "foo", making executable naming more like Unix]

According to Charles Wilson on 3/3/2006 4:16 PM:
> 
> (2)[b] So this is what we did.  And it worked.  Until other people broke
> it by changing cygwin.  So we fixed it.  And now we've got a new cygwin
> option (which I had NEVER heard about until now!) that breaks it again
> -- and the maintainer of coreutils is pushing for more widespread use.

I am subscribed to the libtool lists, and have completed my copyright
papers, so I was planning on bringing the issue of transparent_exe up
there after 2.0 is released if you hadn't yet.

> 
> E.g. pushing to deliberately break libtool
> 
> Eric, please don't *push* CYGWIN=transparent_exe until *somebody*
> implements the following libtool fix.  Sadly, it's too late for any such
> major change to get into libtool-2.0 because libtool is effectively in
> code-slush right now.  But, if *somebody* implements this fix I'll put
> it in cygwin's dist of libtool-2.0 and push for it to go into
> libtool-2.0.x.

Here, I entirely agree with your and Corinna's sentiments.
transparent_exe is an OPTION, and for EXPERIMENTAL USE ONLY, up until we
have enough brave souls willing to hammer out all the cygwin issues,
before it will ever see the light of day (similar to how managed mounts
were).  I am not forcing people to switch to transparent_exe, but also am
interested in being one of those brave souls that makes it work out.  In
the thread that sparked this conversation, I was more worried about
introducing additional foo vs. foo.exe conflicts in a cygwin packaging of
util-linux, rather than tackling the libtool usage.  I am also quite aware
that it won't be overnight for everything to work with transparent_exe.

> 
> The fix:
> ---------

I like your approach, and I will see about lending some of my time towards it.

> 
> Suppose that the following changes were made:
> 
> (1) the binary wrapper takes a command line argument that causes it to
> emit the current contents of the wrapper script on stdout
> 
> (2) the binary wrapper sets the environment variables itself, and then
> exec's the real binary executable directly instead of the wrapper
> script.  This should be relatively easy: just make a copy of **environ,
> modify the entry in that copy with startswith PATH= (adding both the
> .lib dir which contains the target exe, and the .lib dirs which contain
> the DLLs on which it depends), and then use
>    execve(name-of-target-exe, ...)
> instead of
>    execv(name-of-wrapper, ...).
> Watch out for memory allocation issues wrt to the old environ[x] entry
> for PATH and the new one, tho.
> 
> (3) libtool (on cygwin|mingw) would then no longer generate the wrapper
> script.  However, when it needs to source the contents of that script,
> it instead calls
>    'wrapper.exe --emit-script > .lib/wrapper-env-settings
> sources THAT, and then rm -f's it.  Note that (a) the env-settings
> script is both named something other than the actual name of the
> makefile target-without-.exe, AND lives in the .lib subdir.

Sounds right to me.  And I also agree that these steps won't happen until
after libtool 2.0 comes out.


> This would make everybody happy, wouldn't "duplicate" the storage of
> information, would keep the current good behavior of NOT relinking apps
> over-and-over, and could EVEN be extended across all platforms once it's
> working on cygwin/mingw.   But it's a lot of work; fortunately each of
> the three items can be implemented and tested separately.
> 
> But, until these changes happen (and I'm not likely to have time to do
> them myself, although PTC and tested), my answer to complaints is going
> to be a pointer to this post, and "don't use transparent_exe".

http://cygwin.com/ml/cygwin-apps/2006-03/msg00030.html

- --
Life is short - so eat dessert first!

Eric Blake             ebb9 AT byu DOT net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFECjrd84KuGfSFAYARAmHlAKDQKloyLmNFRSfiTdJ/laq0MNSIcgCg2T0Z
Uyi8NdHtD4Fcxx6KhslfumA=
=xsaZ
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/