X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.1 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW,TW_JL,TW_YG
X-Spam-Check-By: sourceware.org
Message-ID: <4C363AA8.7040500@cwilson.fastmail.fm>
Date: Thu, 08 Jul 2010 16:52:56 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
Reply-To: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: cygport patch: suppress libtool fixup step
References: <4C3215FC DOT 3010309 AT cwilson DOT fastmail DOT fm> <1278402537 DOT 5784 DOT 8 DOT camel AT YAAKOV04> <4C337C6E DOT 2080003 AT cwilson DOT fastmail DOT fm> <4C36098F DOT 8030109 AT gmail DOT com>
In-Reply-To: <4C36098F.8030109@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 7/8/2010 1:23 PM, Dave Korn wrote:
> On 06/07/2010 19:56, Charles Wilson wrote:
>
>> To deal with the duplicated DLLs from two different multilib mingw64
>> toolchains (one that supports -m32 and -m64, but *defaults* to -m64, and
>> one that also supports -m32 and -m64, but *defaults* to -m32), the DLLs
>> are actually installed into a completely different directory outside the
>> $triple area.
>>
>> The 64bit dlls are moved manually to $special_prefix/bin64/ and
>> $special_prefix/bin32 -- because these DLLs are "shared" by both
>> toolchains in the specificed -mXX mode, so the "deep" directory inside
>> one toolchain's private area or the other, are both inappropriate.
>
>    In what way are these DLLs "shared"?  They are target libraries, they aren't
> linked into the cross-compiler itself, and applications built by the
> cross-compiler don't link directly against the DLLs anyway, they have import libs.

I guess the term 'shared' is not exact.  Rather, consider the following 
scenario:

1) There exists a mingw64-based gcc, that while defaulting to 64bit 
mode, is multilib and supports also -m32.  When it is built, you will 
get two copies each of (e.g.) libstdc++-sjlj-6.dll, libstdc++.dll.a, 
libstdc++.a, and libstdc++.la.

One of these sets will be 32bit, and the other will be 64bit.

Now, the .la, .a, and .dll.a will all live in
    $prefix/lib/gcc/x86_64-w64-mingw32/VER/      << for 64bit
    $prefix/lib/gcc/x86_64-w64-mingw32/VER/lib32 << for 32bit
since we usually build with --enable-version-specific-runtime.

e.g. $(toolexeclibdir). This is as it should be.

2) Suppose there also exists a separate mingw64-based gcc. Only this one 
defaults to 32bit (it may or may not also be multilib and support -m64; 
that's unimportant here).

When building this compiler, you will get a set of 32bit libs, 
libstdc++-sjlj-6.dll, libstdc++.dll.a, libstdc++.a, and libstdc++.la. 
(If it is multilib, you may also get another matching 64bit set).

Now, in this case the .la, .a, and .dll.a will all live in
    $prefix/lib/gcc/i686-w64-mingw32/VER/      << for 32bit
    $prefix/lib/gcc/i686-w64-mingw32/VER/lib64 << for 64bit, if multilib
since we usually build with --enable-version-specific-runtime.

e.g. $(toolexeclibdir). This is as it should be.

3) Now, if we want to have a *single* consolidated location for the 
$target DLLs -- so that you can actually RUN the stuff you build, 
without a very odd set of $PATH settings -- where should those DLLs go?

The original idea was that there would be a special /bin32 and /bin64 
directory for them.  This has since been refined to a custom "sysroot" a 
la' fedora:

    /usr/sysroot/mingw64-32/bin/  (A)
    /usr/sysroot/mingw64/bin/     (B)

Into (A) would go all the DLLs that are 32bit: the ones from
     $prefix/lib/gcc/x86_64-w64-mingw32/VER/lib32
AND the ones from
     $prefix/lib/gcc/i686-w64-mingw32/VER/

Similarly, into (B) would go all the DLLs that are 64bit: the ones from
     $prefix/lib/gcc/x86_64-w64-mingw32/VER/
AND, if the nominally 32bit mingw64 compiler is also multilib, the ones from
     $prefix/lib/gcc/i686-w64-mingw32/VER/lib64


But...assuming the nominally 64bit but multilib mingw64 compiler, and 
the nominally 32bit (multilib?) compiler have the same version, then you 
will have TWO identical DLLs living at the same location.

Our setup.exe doesn't allow this, and it's bound to cause issues.  So 
the idea was that JonY would pick ONE of each pair as the "blessed" one, 
to be delivered in the (e.g.)

     mingw64-m32-libstdc++6-VER-REL.tar.bz2

package, and in the

     mingw64-m64-libstdc++6-VER-REL.tar.bz2

package.  So, even though you have two compilers that might be thought 
to "own" that installation package, there is only one such package for 
each duplicated DLL, and that package is "shared".

>> But...this is all handled manually, after 'make install'.
>
>    I think it would be cleaner if the right -bindir settings were sent to
> libtool during the build/install process.  This is PR40125(*), btw.  Which I'm
> down to fix, I guess I'd better get on with it.

Well, yes...I agree with Doug Semler that by default, the -bindir 
argument should be $(toolexeclibdir) and not $(bindir) for cross builds.

That would be nice and clean, and would be similar to how .so's are 
normally treated on linux IIRC.  It also makes the most sense for 
$host=not-cygwin, $target=mingw* cross compilers.


I'm just arguing that for the *specific* case where $host=cygwin and 
$target=mingw* (e.g. we know that the underlying platform ALSO supports 
running the "target" executables and DLLs), that as a cygport packaging 
step -- NOT part of gcc's own internal build or install process -- the 
DLLs should be "plucked" from $(toolexeclibdir) and put into a common 
location, which by *policy* on cygwin would be

   "the $(special_prefix)/bin/ directory, where $(special_prefix) is the 
value that shall be passed as --prefix=  when building cygwin-deployed 
packages whose contents are compiled using $host=cygwin, $target=mingw* 
cross compilers"

And the corresponding .la files munged appropriately (again, as a 
cygport postinstall step, not part of the gcc install process per se).

Whether $(special_prefix) is ALSO passed when building the cross 
compiler itself as --sysroot or --build-sysroot, I don't know.

--
Chuck

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