* Providing cygwin1.dll in both 32- and 64-bit versions @ 2017-02-02 21:13 Thomas Nilefalk 2017-02-02 22:10 ` Hans-Bernhard Bröker 0 siblings, 1 reply; 5+ messages in thread From: Thomas Nilefalk @ 2017-02-02 21:13 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Providing cygwin1.dll in both 32- and 64-bit versions 2017-02-02 21:13 Providing cygwin1.dll in both 32- and 64-bit versions Thomas Nilefalk @ 2017-02-02 22:10 ` Hans-Bernhard Bröker 2017-02-03 11:49 ` Thomas Nilefalk 0 siblings, 1 reply; 5+ messages in thread From: Hans-Bernhard Bröker @ 2017-02-02 22:10 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Providing cygwin1.dll in both 32- and 64-bit versions 2017-02-02 22:10 ` Hans-Bernhard Bröker @ 2017-02-03 11:49 ` Thomas Nilefalk 2017-02-03 17:43 ` Hans-Bernhard Bröker 0 siblings, 1 reply; 5+ messages in thread From: Thomas Nilefalk @ 2017-02-03 11:49 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Providing cygwin1.dll in both 32- and 64-bit versions 2017-02-03 11:49 ` Thomas Nilefalk @ 2017-02-03 17:43 ` Hans-Bernhard Bröker 2017-02-10 8:34 ` Thomas Nilefalk 0 siblings, 1 reply; 5+ messages in thread From: Hans-Bernhard Bröker @ 2017-02-03 17:43 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Providing cygwin1.dll in both 32- and 64-bit versions 2017-02-03 17:43 ` Hans-Bernhard Bröker @ 2017-02-10 8:34 ` Thomas Nilefalk 0 siblings, 0 replies; 5+ messages in thread From: Thomas Nilefalk @ 2017-02-10 8:34 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-02-10 8:34 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-02 21:13 Providing cygwin1.dll in both 32- and 64-bit versions Thomas Nilefalk 2017-02-02 22:10 ` Hans-Bernhard Bröker 2017-02-03 11:49 ` Thomas Nilefalk 2017-02-03 17:43 ` Hans-Bernhard Bröker 2017-02-10 8:34 ` Thomas Nilefalk
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).