X-Recipient:	archive-cygwin AT delorie DOT com
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=qBkIs3RlBvfCicqs9YMITdRZFbmqqLnYMioIZ0RLwx4
	FwwMQHG2lwj0zovG24YXZAcixZzvETk/iE4DV3bgYVLdv1/iYaU+L7EfhQG4SEug
	l7VZ5DRQzQl0tTC/Hrmseoq9Ny5Lx2UEzH7bPhaJmliaLQO8DtQCrayQLE+wg0B0
	=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; 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;
	s=default; bh=jAcK3YargdfgBpJu8xC7UMiFHuA=; b=g5tPaNp3EwGKJJRag
	dE6rtJfsgN0qJLRYhzuqVg0hFnlxYm1Gi0/cjdwLitmECQXNPeLtnQD/9TofmBy6
	DQ46zI2MXPQAlbelFGO/4rlyus0/3U/FIWsGiGoBkcwJBJedOuKkCzoAUAXGbq50
	bwEbPVG1+96uqUhXNN0uY9BGb8=
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
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-0.0 required=5.0 tests=BAYES_40,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=internals, Brker, hansbernhard, Hans-Bernhard
X-HELO:	mailrelay5.public.one.com
X-HalOne-Cookie:	e351b9c012a51680a10926f7474233c7a8c35760
X-HalOne-ID:	c7512331-ea06-11e6-b939-b82a72d03b9b
Message-ID:	<58946E36.8070103@junovagen.se>
Date:	Fri, 03 Feb 2017 12:49:10 +0100
From:	Thomas Nilefalk <thomas AT junovagen DOT se>
User-Agent:	Postbox 5.0.9 (Macintosh/20161202)
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Providing cygwin1.dll in both 32- and 64-bit versions
References:	<5893A0CD DOT 5090107 AT junovagen DOT se> <af15cbdf-cfe5-dba9-e293-844a5de19e6a AT t-online DOT de>
In-Reply-To:	<af15cbdf-cfe5-dba9-e293-844a5de19e6a@t-online.de>
X-IsSubscribed:	yes

Hans-Bernhard Bröker skrev:
> Am 02.02.2017 um 22:12 schrieb Thomas Nilefalk:
>
>> Using 'i686-pc-cygwin-gcc' creates an executable but that is un-runnable
>> in a Cygwin64 environment because the cygwin1.dll is a 64-bit version
>> and not compatible with the produced executable. A cygwin32 DLL needs to
>> be put first in the path to make the executable run.
>>
>> Is this by design?
>
> Pretty much, yes.  Windows itself already has a seriously hard time 
> mixing and matching 32-bit and 64-bit executables and their DLLs.  The 
> tricks MS uses to pull that off range from outright scary to 
> Marx-Brothers-grade hilarious, depending how you look at them.
>
> As I see it, Cygwin rightfully opted for sanity here by keeping the 
> two worlds separate.
I'm quite ok with this.

>
>> At least it seems to me that 'gcc -m32' could be
>> taken to mean 'create an executable in the current ABI-environment
>> (cygwin64) which uses a 32-bit architecture'.
>
> No, it really can't.  -m32 does what the GCC documentation says: it 
> makes GCC generate 32-bit x86 code.  Nothing in there so much as 
> suggests that such code will actually work in a given ABI environment. 
> In the case of Cygwin64 it won't.
>
Fair enough.

>> 'how can I make a 32-bit compiled cygwin program run under cygwin64'?
>
> You can't. Nor can anybody else.  For a Cygwin64-based program, 
> Cygwin32 is a bona fide cross-compilation platform rather than just 
> some subset of the same platform.  The same holds vice versa.
What triggered this chain of thought was that running an exe 
cross-compiled to 32-bit just silently failed. When I straced it I got 
the Windows prompt saying "could not start 0xc000007b" (or something 
similar). It took me a while to figure out what was wrong, which 
obviously was that the cygwin1.dll was 64-bit.

It would have helped me at that time if I would have gotten an error 
message from the dynamic loader, like on other platforms ("skipping 
cygwin1.dll because it has the wrong architecture"). I'm not readup on 
cygwin internals enough to understand if this is even possible or if the 
dynamic loader is just the standard Windows one. If it's the standard 
Windows one, we could either hope for a Microsoft action here, or 
wait/suggest/implement some special things in the startup code that did 
this.

Anyways, thanks for the explanation. Given that, the solution for runnig 
32-bit cygwin programs on cygwin64 is of course

     $ PATH=<path_to_32-bit_cygwin1.dll>:$PATH 
<32-bit_cross_compiled_program>

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


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

- Raw text -