From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14334 invoked by alias); 3 Aug 2013 11:33:19 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 14311 invoked by uid 89); 3 Aug 2013 11:33:19 -0000 X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RDNS_NONE autolearn=no version=3.3.1 Received: from Unknown (HELO Ishtar.tlinx.org) (173.164.175.65) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Sat, 03 Aug 2013 11:33:18 +0000 Received: from [192.168.4.12] (Athenae [192.168.4.12]) by Ishtar.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id r73BX7rM007630 for ; Sat, 3 Aug 2013 04:33:10 -0700 Message-ID: <51FCEA73.7030903@tlinx.org> Date: Sat, 03 Aug 2013 11:33:00 -0000 From: Linda Walsh 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: <51F34FA0.50300@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 X-SW-Source: 2013-08/txt/msg00059.txt.bz2 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