fixing MinGW compilation
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49066
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: fixing MinGW compilation
I see that the people developing this are still too deadlocked in the Linux world, i.e. "It works differently on Windows so we cannot support it."
Let's be clear: If someone wants to make a Windows compiler, it has to work with Windows, not with Linux. It has to support Windows features properly, or it's not a Windows compiler!
And if some unimplemented feature creates broken code, it's a bug.
Let's be clear: If someone wants to make a Windows compiler, it has to work with Windows, not with Linux. It has to support Windows features properly, or it's not a Windows compiler!
And if some unimplemented feature creates broken code, it's a bug.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: fixing MinGW compilation
But can the code actually be compiled on VS with or without ASLR? Is there and option for that? According to that statement 'the code is patched at run time'.
May be it works in some special case and something else is required, disabling it like in tdm-gcc would have been easy but they didn't.
Like i said earlier i've got no idea. May be i should ask the MinGW devs?
May be it works in some special case and something else is required, disabling it like in tdm-gcc would have been easy but they didn't.
Like i said earlier i've got no idea. May be i should ask the MinGW devs?
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49066
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: fixing MinGW compilation
To me the reasoning sounds like uninformed bullshit.
Yes, it needs to patch the code at run time. What is needed for that is a relocation table in the executable. Windows's executable format already defines how this has to be done, so I really do not get what the problem for these developers is.
Yes, it needs to patch the code at run time. What is needed for that is a relocation table in the executable. Windows's executable format already defines how this has to be done, so I really do not get what the problem for these developers is.
Re: fixing MinGW compilation
This option is called 'Randomized Base Address' in Visual Studio and it's enabled by default.drfrag wrote:But can the code actually be compiled on VS with or without ASLR? Is there and option for that? According to that statement 'the code is patched at run time'.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: fixing MinGW compilation
As i stated that was something i read somewhere and looked plausible. A software engineer can't be wrong right?
https://insights.sei.cmu.edu/cert/2014/ ... linux.html
I've asked the devs to elaborate in the bug ticket.
https://insights.sei.cmu.edu/cert/2014/ ... linux.html
I've asked the devs to elaborate in the bug ticket.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49066
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: fixing MinGW compilation
There's nothing wrong with what this guy wrote but I do not understand how you could draw any of your conclusions from that.
Like he said: On Windows ASLR is a pure link option, and there's no need to compile code differently for it. That's also what MinGW tries to tell you, but it somehow seems that something is going wrong with it.
Like he said: On Windows ASLR is a pure link option, and there's no need to compile code differently for it. That's also what MinGW tries to tell you, but it somehow seems that something is going wrong with it.
- Chris
- Posts: 2942
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: fixing MinGW compilation
But the question is if it's actually a problem in the toolchain, or a subtle PIE-related bug in GZDoom that just happens to work with MSVC. You need to know where the fault is before you can lay blame._mental_ wrote:You are missing the point. I'm not asking why it's broken.
I'm saying that it should be fixed in toolchain, not in software built with it.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49066
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: fixing MinGW compilation
There is no PIE on Windows. All it does is adding a relocation table to the executable and applying that on startup. So if everything is done right the application should never notice.
Address randomization works perfectly fine with MSVC-created builds in both 32 and 64 bit.
If the game works with PIE off and not with PIE on it just means that the flag that is supposedly ignored on Windows is actually not being ignored and creating broken code.
I haven't forgotten the libsndfile fiasco a year ago where it was also some improperly carried over Linux convention that caused random crashes on Windows where said convention does not apply. We have been using an MSVC build ever since.
Address randomization works perfectly fine with MSVC-created builds in both 32 and 64 bit.
If the game works with PIE off and not with PIE on it just means that the flag that is supposedly ignored on Windows is actually not being ignored and creating broken code.
I haven't forgotten the libsndfile fiasco a year ago where it was also some improperly carried over Linux convention that caused random crashes on Windows where said convention does not apply. We have been using an MSVC build ever since.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: fixing MinGW compilation
That was what i meant, gcc tries to compile code differently. The flag is ignored with tdm-gcc but not with MinGW-w64. I dunno why.Graf Zahl wrote:On Windows ASLR is a pure link option, and there's no need to compile code differently for it. That's also what MinGW tries to tell you, but it somehow seems that something is going wrong with it.
- Chris
- Posts: 2942
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: fixing MinGW compilation
Which, as I understand it, is done the same as with a DLL, which I'm positive MinGW-w64 works fine for. So it's not just the position-independent stuff that's breaking something.Graf Zahl wrote:All it does is adding a relocation table to the executable and applying that on startup.
Looking at commit 25d53ecd, it adds -fPIE to ALL_C_FLAGS, and -pie to the linker flags. Checking the GCC man page, it says:
So there could be a problem here. -fPIE is used for compilation (I'm assuming for both C and C++?), while -pie is added to the linker without -fPIE, which the man pages say should be specified for the link. Being inconsistent with build flags can certainly be the cause of a broken build.-pie
Produce a position independent executable on targets that support it. For predictable
results, you must also specify the same set of options used for compilation (-fpie,
-fPIE, or model suboptions) when you specify this linker option.
One other thing to note is that commit adds a check for __PIC__, but -fPIE defines __PIE__ instead.
Re: fixing MinGW compilation
-fPIE is a compiler option and -pie is a linker one. Both were added to appropriate variables.
Do you mean that -fPIE should be added to linker options too?
About __PIC__ vs. __PIE__. I tested that on Ubuntu 16.04 and 32-bit version it didn’t build without this check extended.
Addition of __PIC__ solved this. I don’t remember why it wasn’t __PIE__, sorry.
But I don’t really understand how this will help with 64-bit MinGW build. It should not have any effect there.
Do you mean that -fPIE should be added to linker options too?
About __PIC__ vs. __PIE__. I tested that on Ubuntu 16.04 and 32-bit version it didn’t build without this check extended.
Addition of __PIC__ solved this. I don’t remember why it wasn’t __PIE__, sorry.
But I don’t really understand how this will help with 64-bit MinGW build. It should not have any effect there.
- Chris
- Posts: 2942
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: fixing MinGW compilation
That seems to be what GCC's docs say._mental_ wrote:Do you mean that -fPIE should be added to linker options too?
Apparently it does. It's not necessary for ASLR, but apparently -fPIE does add relocation info to the executable like DLLs have. MinGW32 ignored the switch while MinGW-w64 handles it as intended, but it's incorrectly applied to the linker so it doesn't link the executable correctly.But I don’t really understand how this will help with 64-bit MinGW build. It should not have any effect there.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49066
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: fixing MinGW compilation
... and that's clearly not correct on the toolchain's side. Even on Linux it strikes me as odd that the linker needs manual help to do it right.Chris wrote: Apparently it does. It's not necessary for ASLR, but apparently -fPIE does add relocation info to the executable like DLLs have. MinGW32 ignored the switch while MinGW-w64 handles it as intended, but it's incorrectly applied to the linker so it doesn't link the executable correctly.
Re: fixing MinGW compilation
My comment was about __PIC__ vs. __PIE__ only. If -fPIE switch for linker solves the issue, sure it was my mistake. Like I said, it was tested on particular Linux distro where executable runs fine without this linker option.Chris wrote:Apparently it does. It's not necessary for ASLR, but apparently -fPIE does add relocation info to the executable like DLLs have. MinGW32 ignored the switch while MinGW-w64 handles it as intended, but it's incorrectly applied to the linker so it doesn't link the executable correctly.
- Chris
- Posts: 2942
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: fixing MinGW compilation
How else is the linker supposed to know it has to handle relocation if you don't tell it? If you compile using functions from a third-party lib, you have to tell the linker to use that lib. The -pthread switch is similar; you compile with it to tell the compiler to use re-entrant versions of functions when possible and automatically use pthread functions where needed. Then when linking, you specify -pthread to auto-set the necessary link options and pull in the necessary libs that code compiled with -pthread might need.Graf Zahl wrote:... and that's clearly not correct on the toolchain's side. Even on Linux it strikes me as odd that the linker needs manual help to do it right.