Providing cygwin1.dll in both 32- and 64-bit versions

[Thomas Nilefalk]

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