This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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




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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]