Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] RCP Debugger for Windows?

Hi kessel,

I don't think we should necessarily abandon GCC and GDB on Windows but there is a need for supporting the Visual Studio toolchain for several reasons:
1. Some large projects were written for Visual C++ compiler and moving to GCC is not trivial
2. Even if they could move to GCC, a lot of libraries are incompatible with the compiled binaries. I have in mind all the libraries provided by Microsoft such as DirectX which are troublesome (if not impossible?) to make it work with GCC compiled binaries. I'm just speaking from personal experience so correct me if I'm wrong.

More comments below.

On 7/22/2015 6:17 PM, kesselhaus wrote:

I'm a bit concerned about, how that discussion started and was going into strange directions from my point of view.
GCC which you actually support currently is in my opinion not the problem.
It's not only mingw and cygwin out there. I think, I stated this some time ago already, that e.g. at, they provide a GCC distribution of 32bit and 64bit for windows (even latest 5.1 versions and snapshots), and also include GDB and make.

There is MinGW (original), Cygwin, MinGW-64, MinGW2 and the Equation one (maybe more?). Which one should CDT focus on? So far, it has been a best effort to make them all work, depending on what users report (Bugzilla, forums). I think this will probably still be the same approach in the future (best effort). I personally test things with MinGW (mingw-get installer) on occasion.

I guess, what your main problem is, is the build environment not being a UNIX shell like, but windows command prompt based.
So, there is no rm -f *.o or similar things, but the internal builder will work quite nicely, and produce the same usable binaries, which can be debugged in CDT.
Therefore, the most critical part here is actually, how to build the beast, not calling the tools or paths or debugging.

The question is always, why you need a UNIX shell like environment on Windows, be it cygwin or mingw.
Maybe we just need other build toolchains, that are more abstracting from the actual OS.
e.g. scons or waf or cmake might be viable solution. But just keeping the UNIX like makefile based MBS build system is problematic.

I don' think the main challenge for GCC/GDB on Windows is the shell but rather compatibility with libraries, existing code base support, etc. The rm bug can be worked around multiple ways (the internal builder being one of them).

If you want to switch to VC++ support, is not an option for everybody. Where do you get the compiler from? Is it still distributed by Microsoft separately from Visual Studio in the SDK?
I've heard, it's not included anymore, but I could be wrong.
The other thing with VC++ is, that the compiler does e.g. not support C99. It's C90, maybe they'll put in some C11 in the near future.
I'm not sure, if somebody downloads >500MB of community or express edition is then going to use Eclipse/CDT; my guess is, they are just using VS then.

I don't think people would choose VS over Eclipse because of just download size. At least, I hope not! I personally used Eclipse alongside a full VS 2010 and VS2008 for years because I preferred programming in Eclipse. I don't think it would be that much to ask to download the toolchain as part of VS community edition or Windows SDK. Also, on Mac, you used to have to download the whole Xcode to get the command line tools (there's a command line way now) and I think people were OK with that. It's also possible that Microsoft will release command line tools as a separate download in the future, stranger things have happened!

Regarding the Clang/LLVM, I wonder if they now start to support Windows or not. There have been releases of Clang/LLVM, where either there was no release for Windows, or it was missing major libraries (headers and libs), a point where I always rejected to even look at Clang/LLVM. Without the stdlib, how am I supposed to get a running binary. And then they provide maybe an major release of Clang/LLVM, but minor bugfixes do not provide a binary for windows, whatever the bugfix releases were about (the information is about lacking). Look into the 3.4, 3.5.
A lot of users are not able to build the compiler themself, they want to install the update and that's it. That is like if you might use a Linux Fedora/Suse/Debian/Ubuntu.. or you use Gentoo.

I see they release Clang binaries for Windows now. I think the idea is to have it compatible with the VC++ runtime so that's what you would link against that to get standard libraries, right?

e.g. in my company (Automotive embedded software), we are thinking to change from VC++ based Cantata Unit testing to gcc-based unit testing.
One thing is, that using Jenkins as CI tool, compiling the unit tests with gcc is much easier than with VC++ solutions.
Our toolchain is currently based on makefiles, but we are changing to scons or similar environment.

You can use nmake, cmake and others to use CL as the compiler instead of using solutions.

I don't think this needs to be a GCC/GDB vs Visual Studio discussion. We can keep "supporting" GCC and GDB on Windows as a best effort, as we always have. But there are a lot of other popular tools out there that need to be more smoothly integrated so that users can adopt CDT. In any case, I'm not aware of anyone working on CDT that need to support Windows "officially" so I'm not sure how much is going to be done in this area.



Am 15.07.2015 um 18:31 schrieb Doug Schaefer:
Interesting. Having said that, I decided to take another look at mingw-64, the good fork of mingw. They actually do have an installer that is packaging up the latest compiler and includes gdb. You can get it here:

It would be cool if CDT could install the toolchain for you...


From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Doug Schaefer [dschaefer@xxxxxxx]
Sent: Wednesday, July 15, 2015 11:15 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] RCP Debugger for Windows?

I’m pretty concerned about the state of local Windows development anyway. Cygwin messes us up by being to Linux-y with it’s file paths, MinGW has forked with the old one moving too slow and being 32-bit only and the new one not having a consistent packaging mechanism. We should always declare a toolchain we “officially” support but I’m not sure we can do that for Windows at the moment.

Part of me suggests we should abandon the GNU world on Windows, focus on better support for Microsoft’s toolchain. But that’s a lot of work that someone would have to do for free since I don’t see a lot of commercial value there.

Maybe Clang/LLDB will help but it’s not clear how much they are focused on Windows either.

Which is all to bad, I think Windows 10 will start to appeal to engineers again and I don’t see it going away. It’s what most students, hobbyists, game developers, etc. are using. We should try and figure out a good strategy there.


From: <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Marc-André Laperle <marc-andre.laperle@xxxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Wednesday, July 15, 2015 at 9:56 AM
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] RCP Debugger for Windows?

Not really. No one asked for it though. Did someone talk to you about it? It's a bit of extra work to set the icons, add a few OS specific plugins and testing. I wasn't sure there was a real demand for it since there is WinDbg already. I can add Windows support easily if people want it (and other OS and architectures).


From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Marc Khouzam [marc.khouzam@xxxxxxxxxxxx]
Sent: Wednesday, 15 July 2015 9:08 AM
To: CDT DEV (cdt-dev@xxxxxxxxxxx)
Subject: [cdt-dev] RCP Debugger for Windows?


is there a technical reason why we don't provide the new RCP Debugger for Windows?



cdt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

cdt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top