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