fixing MinGW compilation

[Graf Zahl]

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.

[drfrag]

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?

[Graf Zahl]

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.

[_mental_]

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

This option is called 'Randomized Base Address' in Visual Studio and it's enabled by default.

[drfrag]

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.

[Graf Zahl]

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.

[Chris]

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.

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.

[Graf Zahl]

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.

[drfrag]

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.

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.

[Chris]

All it does is adding a relocation table to the executable and applying that on startup.

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.

Looking at commit 25d53ecd, it adds -fPIE to ALL_C_FLAGS, and -pie to the linker flags. Checking the GCC man page, it says:

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

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.

One other thing to note is that commit adds a check for __PIC__, but -fPIE defines __PIE__ instead.

[_mental_]

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

[Chris]

Do you mean that -fPIE should be added to linker options too?

That seems to be what GCC's docs say.

But I don’t really understand how this will help with 64-bit MinGW build. It should not have any effect there.

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.

[Graf Zahl]

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.

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

[_mental_]

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.

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]

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

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.