search

ldc-developers / ldc

The LLVM-based D Compiler.
http://wiki.dlang.org/LDC
Other
1.18k stars 255 forks source link

Unable to build MinGW version #1121

Open redstar opened 8 years ago

redstar commented 8 years ago

It is currently not possible to build a MinGW version.

Reason is that the MinGW runtime is a mix between all defined C runtimes. E.g. FILE is defined like in CRuntime_DigitalMars but other declarations are in CRuntime_Microsoft. IMHO this needs to be fixed upstream.

dnadlinger commented 8 years ago

This needs to be fixed upstream, but we shouldn't release a version without working MinGW support. 32 bit Windows is way more interesting as a target to most than Solaris or FreeBSD.

kinke commented 8 years ago

We could also opt to go with MSVC for Win32 too. That would mean extending some version(Win64) paths in the runtimes to version(Windows). Not sure how compatible this would be wrt. upstream DMD. Afaik, DMD uses its own DigitalMars runtime on Win32. With VS 2015 C99 compatibility, the MSVC runtime should expose a pretty similar interface, so my guess is it wouldn't be that hard.

I just think there's not that much of a point in MinGW(-x64) (a runtime layer on top of Microsoft's runtime providing missing C99/POSIX functionality) anymore since MS added near-complete C99 support in their latest runtime. MinGW additionally provides 80-bit x87 support, but that's probably not of much interest anymore.

Additionally, I don't think there's much of a point in using 32-bit on Windows anymore. :P

redstar commented 8 years ago

What would be the right way? Define a new CRuntime_MinGW?

redstar commented 8 years ago

@kinke We need to rewrite the exception handling code for Win32 MSVC. It compiles fine but even a trivial application doesn't link because of the missing EH support. (Tried it some hours ago.)

kinke commented 8 years ago

Oh I see. Afaik, that will be handled by LLVM in the future, but it's probably going to take some more months.

bruno-medeiros commented 8 years ago

The point of MinGW is so that you can use GDB to debug programs compiled with LDC, which is quite a big thing.

kinke commented 8 years ago

What? Using gdb on Windows wouldn't even cross my mind; I'd rather suggest compiling & debugging in a Linux VM if need be. It's just a matter of some more time until we get proper .pdb support in LDC as MS is committed to officially adding it to LLVM, paving the way for 'native' Visual Studio/WinDbg debugging.

bruno-medeiros commented 8 years ago

Using gdb on Windows wouldn't even cross my mind; I'd rather suggest compiling & debugging in a Linux VM if need be

Are you seriously suggesting that debugging with GDB in a Linux VM is more practical than simply using GDB on Windows directly? The whole development environment would have to be run in Linux (compilation, IDE/editors, etc.) for that to be practical, and that would basically boil down to using Linux in the first place, which I don't want to do (VM or not).

LLDB support for native VS debugging format is promising, but we're not there yet. And also LLDB IDE integration is not widespread, as it is for GDB. For example I can use Eclipse GDB integration to debug programs in Windows (well, in C/C++ and Rust... But not in D).

dnadlinger commented 8 years ago

I agree – even though 32 bit MSVC support might have a lot of benefits, it is simply nowhere near production quality right now. And at least as long as this is a case, MinGW remains a strategically important target. Debugging is just one aspect of it.

At the same time, however, one would hope that somebody who is interested in it (Bruno? ;)) would just go ahead and contribute the changes to make the 32 bit MinGW Phobos compile again. It's probably just shuffling a couple of version statements around, and I would be surprised if it required knowledge of compiler internals at all.

bruno-medeiros commented 8 years ago

Hum, it shouldn't require knowledge of DMD frontend internals, but surely it must require some knowledge of LLVM and/or mingw internals, of which I know nothing about...

dnadlinger commented 8 years ago

I think the reason why it broke is just that some versions were changed in the upstream Phobos repo. All the stuff that touches internals should be already figured out since a few years ago at this point.

kinke commented 8 years ago

Are you seriously suggesting that debugging with GDB in a Linux VM is more practical than simply using GDB on Windows directly?

Not more practical of course, I just would have never thought about using gdb on Windows. The whole MinGW ecosystem always seemed so alien on Windows and probably puts off the vast majority of regular Windows devs. Anyway, I'm just saying that from my point of view, MinGW has no future. Open source libraries using GCC-flavoured C(++) (not compilable straight away with VS) are handled well by Clang; the MinGW runtime is mostly obsolete since VS 2015; and we'll get native EH + debugging support in LLVM soon. That's why I won't invest any time on it and think we should focus our very limited manpower on MSVC, following LLVM/Clang. No objections to others' contributions though. ;)

bruno-medeiros commented 8 years ago

Not more practical of course, I just would have never thought about using gdb on Windows. The whole MinGW ecosystem always seemed so alien on Windows and probably puts off the vast majority of regular Windows devs.

MinGW works fine on Windows if you are developing cross-plaftorm (or more correctly, non-Windows specific code). Only if you are developing against Windows libraries (DirectX for example), that things get weird using MinGW. I do admit that's likely the most common scenario for Windows devs, by far.

@kinke Judging from your comments, does this mean fixing building on MingW is not really a smallish task?

kinke commented 8 years ago

Nope, I guess it's really just a bunch of wrong version() paths, mainly in druntime, but finding them may be a bit tedious. I'd start by fixing any druntime/Phobos compile errors and then checking the failing unittests - there will presumably be some ugly crashes, e.g., when passing a FILE struct with a wrong layout. But here gdb could be used to track them down. :)

Another route would be revising all version(CRuntime_*) blocks and comparing against the MinGW C headers if in doubt.

redstar commented 8 years ago

The stuff for MinGW is present in druntime/Phobos. As @kinke said you have to solve a puzzle: which of the pieces are required for MinGW? It is not really complicated (hint: I am looking for pull requests!), only time consuming.

dnadlinger commented 8 years ago

@kinke: http://blogs.msdn.com/b/vcblog/archive/2015/11/18/announcing-the-vs-gdb-debugger-extension.aspx ;)