DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=YBvMUU56TwLlddEg3c5gcyXEvYau3qW4DFK6PpfVQR6
	O+/qYiGyV6FMEZyqk7dbTJtIzlNh7aXR+QCeUF5PZ6s932VLVsU6/7UQIIG27qQj
	8xes8HRdFGVahI7l3EEObhc/okV0bW4ZnIa2FNrCVHrx6W0zxk+m2E1xolMft19I
	=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Message-ID: <51FCEA73.7030903@tlinx.org>
Date: Sat, 03 Aug 2013 04:33:07 -0700
From: Linda Walsh <cygwin@tlinx.org>
User-Agent: Thunderbird
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: having 1 set of non-bin files w/separate {bin,lib}[32/64)? (was Re: please update the supported Cygwin package list ...)
References: <CADex0xxLK3LRfHcat8UYXDUoYxRu5OPzV0_+FXMKd7k_J4G+Vg@mail.gmail.com>	<51F34FA0.50300@gmail.com> <CADex0xwDTvHaOS-_xAr3pARiBQ19zAdOS8US06r+E14b65SC-w@mail.gmail.com> <51F35E4A.4040207@gmail.com> <51F368C4.5030309@etr-usa.com> <51F9A3BE.4020907@tlinx.org> <51F9ABA0.3090205@etr-usa.com>
In-Reply-To: <51F9ABA0.3090205@etr-usa.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Warren Young wrote:
>> then maybe in your bashrc have
>> it do a cygmount or create a softlinke from /bin32 -> /bin or 
>> /bin64->/bin
>> (and same for lib)?
> 
> You can't just merge the two bin/lib dirs.  The executable names 
> conflict.  My solution involving a "cygwin2.dll" is the only solution I 
> see.  And again, it's packed with potential pain.
---
Sorry, didn't mean to be misunderstood ;-).

I meant if something (pie in the sky?) in a bash startup script
(maybe always running out of the 32-bit dir for arguments sake),
could mount directories ... neh....only if everything was running
32/64... windows only implemented redirection insides the /windows
folder...

hmmm...
so if one put the cygwin 32-bit binaries under /windows/syswow64
and the 64-bit binaries under /windows/sysnative (as seen by 32bit)
or system32 when running 64, then a program would always be
able to refer to say, /windows/system32/cygwin/{bin,lib} as hard
paths -- and 32-bit binaries would always be redirected to /windows/syswow64
while 64-bit binaries would really access the stuff natively/directly.

It seems to be the only reliable 32-bit redirection -- and MS chose to put
it in the /windows dir... so they must want customers to put anything needing
that feature in that dir...right?? ;-)  Oi...

Seriously, it might not be the most loved location, but it is the only one
that would work and allow auto translation.

A link made with mklink forms a symlink, so they could be used to point at
the dir location under system32 ... but 32-bit processes would be autodirected to
the syswow64 dir....

Dang... nowif you can think of another way to do it automatically and not
change names etc...

It might be possible to just put symlinks in system32 and syswow, that would
be seen by 64-bit and 32-bit procs that point to real dirs located in the
root of the vol (/cygwin or /...)...that likely would be better -- less junk
in the windir... but the links would still have to travel through the redirector.


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