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

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

[Thomas Nilefalk]

I'm cross-compiling on Cygwin64 to 32-bit. Or rather I'm trying to 
figure out what compiling to 32-bits on a Cygwin64 actually means.

Using 'gcc -m32' causes a lot of "skipping incompatible ..." for a lot 
of libraries, so obviously ld then looks for the 32-bit libraries in the 
"wrong" place.

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? 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'. I'm not sure that makes 
sense or is even possible, but if it is not, then the question becomes 
'how can I make a 32-bit compiled cygwin program run under cygwin64'?

One way to answer that is to say "export 
PATH=<path_to_32_bit_cygwin1.dll>:$PATH" but that requires installing 
cygwin32.

I understand that could be the semantics of "cross-compilation" (you 
could compile for any platform, and can't expect that to run in your 
host environment), but then I'd like to propose that "-m32" should/could 
mean compile for host using 32-bit restrictions.

Which part of this is true? Is there a bug with "-m32" or am I just 
misunderstanding everything?

/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

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

[Hans-Bernhard Bröker]

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.

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

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

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

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

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

[Hans-Bernhard Bröker]

Am 03.02.2017 um 12:49 schrieb Thomas Nilefalk:
> Hans-Bernhard Bröker skrev:
>> Am 02.02.2017 um 22:12 schrieb Thomas Nilefalk:

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

BTDT, and can feel your pain.

> 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").

Welcome to one of the deeper levels of the tragedy (or comedy of 
errors...) commonly known as Windows "DLL hell".  AFAIK there is no 
dynamic loader Cygwin would have any amount of control over.  This fails 
before any part of Cygwin ever gets loaded, so there's practically 
nothing cygwin can do about it.

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

Actually that's not the solution, either.  It's an unreliable workaround 
at best.  That's because after this, all 64-bit cygwin programs executed 
by your own program will fail to start because they get the wrong Cygwin 
DLL.

The solution is to have a Cygwin32 environment installed independently 
of Cygwin64, and keep each executable strictly in its own environment. 
Mixing the two causes nothing but problems.

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

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

[Thomas Nilefalk]

Hans-Bernhard Bröker skrev:
> Am 03.02.2017 um 12:49 schrieb Thomas Nilefalk:
>> Hans-Bernhard Bröker skrev:
>>> Am 02.02.2017 um 22:12 schrieb Thomas Nilefalk:
>
>>>> '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.
>
> BTDT, and can feel your pain.
>
>> 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").
>
> Welcome to one of the deeper levels of the tragedy (or comedy of
> errors...) commonly known as Windows "DLL hell". AFAIK there is no
> dynamic loader Cygwin would have any amount of control over. This fails
> before any part of Cygwin ever gets loaded, so there's practically
> nothing cygwin can do about it.
>
>> 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>
>
> Actually that's not the solution, either. It's an unreliable workaround
> at best. That's because after this, all 64-bit cygwin programs executed
> by your own program will fail to start because they get the wrong Cygwin
> DLL.
>
> The solution is to have a Cygwin32 environment installed independently
> of Cygwin64, and keep each executable strictly in its own environment.
> Mixing the two causes nothing but problems.
>

Emperical data suggests that:

 > Thomas@thoni64:[x86_64] ~/Utveckling/ToolMaker
 > $ file bin/pmk
 > bin/pmk: PE32 executable (console) Intel 80386, for MS Windows
 >
 > Thomas@thoni64:[x86_64] ~/Utveckling/ToolMaker
 > $ bin/pmk
 >
 > Thomas@thoni64:[x86_64] ~/Utveckling/ToolMaker
 > $ PATH=/cygdrive/c/cygwin32/bin:$PATH bin/pmk
 > Usage: /cygdrive/c/Users/Thomas/Utveckling/ToolMaker/bin/pmk [-help 
[options] <input file>
 >
 > Thomas@thoni64:[x86_64] ~/Utveckling/ToolMaker
 > $ PATH=$PATH:/cygdrive/c/cygwin32/bin bin/pmk
 > Usage: /cygdrive/c/Users/Thomas/Utveckling/ToolMaker/bin/pmk [-help] 
[options] <input file>

The first run is evidence that on an x86_64, running a 32-bit exe 
silently exits. But note that adding the 32-bit cygwin1.dll to the path, 
even at the end like in the last command, will allow the loader to find 
that instead of the 64-bit one.

This is good news because it allows you to, at least in some cases, run 
32-bit cygwin-dependent programs in a 64-bit Cygwin.

Although as you say, mixing the environments in a more general sense, 
would probably mostly cause confusion because of other issues, like 
non-cygwin-DLL:s (which would need similar treatment) and other shared, 
but not equal, resources from the two environments.

The other way around does not seem to work, though. So it seems that you 
can't run 64-bit cygwin-dependent exes in a 32-bit environment by adding 
the 64-bit cygwin1.dll to the path. Which kind of makes sense, given 
backwards compatibility thinking.

I'm happy because my discovery solves my particular need (which is not 
generally mixing 32 and 64-bit environments). Maybe someone else can 
benefit from this. Although I am definitely not assuming this is by 
design (it might be, you never know what MS actually are thinking) and 
will not rely on it working for the future.

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