Why Not Use "Cl.exe Link.exe" as the primary compiler?

Ask your support questions in here

Moderator: Moderator Team

melen523
Posts: 2
Joined: Tue Mar 12, 2013 11:32 am

Why Not Use "Cl.exe Link.exe" as the primary compiler?

Post by melen523 »

As the topic says.
melen523
Posts: 2
Joined: Tue Mar 12, 2013 11:32 am

Re: Why Not Use "Cl.exe Link.exe" as the primary compiler?

Post by melen523 »

Ah i know , in that case , the code would not be easy to compile cross platform
hbelusca
Developer
Posts: 1197
Joined: Sat Dec 26, 2009 10:36 pm
Location: Zagreb, Croatia

Re: Why Not Use "Cl.exe Link.exe" as the primary compiler?

Post by hbelusca »

But we support compiling ReactOS with Visual C++ !
Yuntian Zhang
Posts: 11
Joined: Wed Apr 24, 2013 3:16 am

Re: Why Not Use "Cl.exe Link.exe" as the primary compiler?

Post by Yuntian Zhang »

1. GCC has been ported to multi platform. But VC is Windows only. Of course you can use Wine, but that isn't supported officially, which means Microsoft can detect it and refuse to run if they want.
2. GCC is open source and libre. As an open source project under GPL, there is no reason not to support another open source project.
3. GCC, if not better than VC, is as good as VC. If GCC really sucks, although it is under GPL blah blah blah we won't use it. But it works flawlessly.
4. VC doesn't fully support C99, nor C11. Microsoft has tried to push their users to use C++. ALthough I didn't type it, VC means "Visual C++", not "Visual C". In this project the basic programming language is C. No point to use VC for compiling C source codes.

Those are what I come up with right now.
Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: Why Not Use "Cl.exe Link.exe" as the primary compiler?

Post by Z98 »

We require C89 for all C code, so VC++'s lack of support for newer versions of C is irrelevant. Several developers are already using VC++ to do much of their work. The only thing that stopped them in the past was our build configuration system could not correctly support it. With CMake (plus a few patches of our own), we now can. It's a moot point however as not everyone can run VC++, so we maintain compatibility with GCC for practical reasons.
BlackRabbit
Posts: 128
Joined: Sat Dec 22, 2012 7:36 am

Re: Why Not Use "Cl.exe Link.exe" as the primary compiler?

Post by BlackRabbit »

With CMake (plus a few patches of our own), we now can.
Really? If so, I must be confused. I have been attempting to compile using the cmake method, on average, about once a week since it was first announced a few months ago. I have not yet had any success. I must be doing something wrong.

Could someone please clarify what to expect with the cmake method? I am not so much interested in how to compile with cmake. I know how to do that (I think). I am more interested in the answers to the following questions:
  1. Does Intellisense work using after loading the cmake-generated Visual Studio solution and project files?
  2. If I download a virgin ReactOS/cmake build bundle and follow the instructions for building using cmake, will I be able to at least compile all of ReactOS without any fatal build errors?
  3. Is it possible to use the Visual Studio-via-cmake method to build livecd?
  4. Is it possible to use the Visual Studio-via-cmake method to build bootcd?
Each time I broach this subject, I am told that cmake works with Visual Studio, but when I try it myself, it fails. When I bring it to someone's attention that it fails, I am told something like, "It is not working yet."

Also note that, by my question, I am not implying that, for example, #3/#4 should be true. I am merely trying to gain some perspective here.
Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: Why Not Use "Cl.exe Link.exe" as the primary compiler?

Post by Z98 »

1) Yes.
2) Mostly, minus some C++ components. Note I am assuming you mean Visual C++ here, since cmake is not a compiler.
3) Same as 2, with the qualifier that there are known bugs that make things a bit unstable and thus is not used for debugging purposes.
4) Low priority amongst the devs so who knows.

So far amongst the team, no one seems to have any difficulty getting a build going, but then we're only using it for debugging user mode modules. Regression testing is only run against GCC builds. You keep insisting that you can't get it to work, but we haven't been given sufficient/precise enough information with which to try to replicate your problems.

And please be more precise in your terminology. You keep treating the names of a compiler, a build system, and a build generator as interchangeable. They are not, which only adds to the confusion whenever you report a problem.
erkinalp
Posts: 860
Joined: Sat Dec 20, 2008 5:55 pm
Location: Izmir, TR

Re: Why Not Use "Cl.exe Link.exe" as the primary compiler?

Post by erkinalp »

Z98 wrote:We require C89 for all C code, so VC++'s lack of support for newer versions of C is irrelevant. Several developers are already using VC++ to do much of their work. The only thing that stopped them in the past was our build configuration system could not correctly support it. With CMake (plus a few patches of our own), we now can. It's a moot point however as not everyone can run VC++, so we maintain compatibility with GCC for practical reasons.
If we cease Visual Studio support, lack of C99/C11 will become important, new C APIs has multithreading and safe functions, and we can attract much more developers from *nix to ReactOS (I mean user side applications).
-uses Ubuntu+GNOME 3 GNU/Linux
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2
BlackRabbit
Posts: 128
Joined: Sat Dec 22, 2012 7:36 am

Re: Why Not Use "Cl.exe Link.exe" as the primary compiler?

Post by BlackRabbit »

I decided to do everything from scratch so that we are all on the same wavelength:
  1. I am using Visual C++ Express 2010.
  2. I pull the ReactOS source tree from the ReactOS server.
  3. I go to the root of my ReactOS tree and type configure VSSolution. The configure command does its thing, generating the Visual Studio solution and project files.
  4. I load the solution for the host tools and do a build inside Visual Studio. The build completes successfully, with no errors whatsoever.
  5. I load the solution for ReactOS proper, and do a build all. As you mentioned, I get a relatively small number of errors:
Some errors are related to browseui.dll:
Visual C++ Express 2010 Output Window wrote: ------ Rebuild All started: Project: browseui, Configuration: Debug Win32 ------
Building Custom Rule C:/Users/BlackRabbit/Desktop/reactos/dll/win32/browseui/CMakeLists.txt
CMake does not need to re-run because C:\Users\BlackRabbit\Desktop\reactos\output-VS10-i386\reactos\dll\win32\browseui\CMakeFiles\generate.stamp is up-to-date.
Generating browseui.def, browseui_stubs.c
aclmulti.cpp
uuid.lib(shguids.obj) : error LNK2005: _FOLDERID_AddNewPrograms already defined in shell32.lib(shguid.obj)
uuid.lib(shguids.obj) : error LNK2005: _FOLDERID_AdminTools already defined in shell32.lib(shguid.obj)
...
uuid.lib(shguids.obj) : error LNK2005: _FOLDERID_Windows already defined in shell32.lib(shguid.obj)
Creating library C:/Users/BlackRabbit/Desktop/reactos/output-VS10-i386/reactos/dll/win32/browseui/Debug/browseui.lib and object C:/Users/BlackRabbit/Desktop/reactos/output-VS10-i386/reactos/dll/win32/browseui/Debug/browseui.exp
C:\Users\BlackRabbit\Desktop\reactos\output-VS10-i386\reactos\dll\win32\browseui\Debug\browseui.dll : fatal error LNK1169: one or more multiply defined symbols found
Some errors are related to shell32.DLL:
Visual C++ Express 2010 Output Window wrote: ------ Rebuild All started: Project: shell32, Configuration: Debug Win32 ------
Building Custom Rule C:/Users/BlackRabbit/Desktop/reactos/dll/win32/shell32/CMakeLists.txt
CMake does not need to re-run because C:\Users\BlackRabbit\Desktop\reactos\output-VS10-i386\reactos\dll\win32\shell32\CMakeFiles\generate.stamp is up-to-date.
Generating shell32.def, shell32_stubs.c
uuid.lib(shguids.obj) : error LNK2005: _FOLDERID_AddNewPrograms already defined in shell32.lib(shguid.obj)
...
uuid.lib(shguids.obj) : error LNK2005: _FOLDERID_Windows already defined in shell32.lib(shguid.obj)
Creating library C:/Users/BlackRabbit/Desktop/reactos/output-VS10-i386/reactos/dll/win32/shell32/Debug/shell32.lib and object C:/Users/BlackRabbit/Desktop/reactos/output-VS10-i386/reactos/dll/win32/shell32/Debug/shell32.exp
C:\Users\BlackRabbit\Desktop\reactos\output-VS10-i386\reactos\dll\win32\shell32\Debug\shell32.dll : fatal error LNK1169: one or more multiply defined symbols found
And some errors are related to the HAL.
Visual C++ Express 2010 Output Window wrote: ------ Rebuild All started: Project: hal, Configuration: Debug Win32 ------
Building Custom Rule C:/Users/BlackRabbit/Desktop/reactos/hal/halx86/CMakeLists.txt
CMake does not need to re-run because C:\Users\BlackRabbit\Desktop\reactos\output-VS10-i386\reactos\hal\halx86\CMakeFiles\generate.stamp is up-to-date.
Generating hal.def, hal_stubs.c
hal.def : error LNK2001: unresolved external symbol KeStallExecutionProcessor
C:/Users/BlackRabbit/Desktop/reactos/output-VS10-i386/reactos/hal/halx86/Debug/hal.lib : fatal error LNK1120: 1 unresolved externals
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(268,5): error MSB6006: "link.exe" exited with code 1120.
As you stated, the total number of projects that fail to build is relatively small:
Visual C++ Express 2010 Output Window wrote: ------ Skipped Rebuild All: Project: ALL_BUILD, Configuration: Debug Win32 ------
Project not selected to build for this solution configuration
========== Rebuild All: 813 succeeded, 7 failed, 4 skipped ==========
First clarification: I think that it is very important to make it clear that it is not yet possible to build ReactOS using Visual Studio. It is possible to build most of the components of ReactOS using Visual Studio. This distinction is very important for those who prefer Visual Studio but are not yet familiar with the build system, especially new developers, because it removes any expectations that they are going to be able to generate a livecd using Visual Studio. When you say, that it is possible to build ReactOS using cmake-Visual Studio method, some people might get the impression that, if they follow the steps, a livecd will be generated, which they can then use to play with.

Second clarification: I went to the ntoskrnl project, opened shutdown.c, right-clicked on NtSetSystemPowerState, and selected Go To Declaration:

[ external image ]

I get the following error:

[ external image ]

It is true that mousing over NtSetSystemPowerState, for example, will show the function prototype in a pop-up. But being able to browse-around by doing Go To Declaration does not seem to work.
BlackRabbit
Posts: 128
Joined: Sat Dec 22, 2012 7:36 am

Re: Why Not Use "Cl.exe Link.exe" as the primary compiler?

Post by BlackRabbit »

erkinalp wrote:If we cease Visual Studio support, lack of C99/C11 will become important, new C APIs has multithreading and safe functions, and we can attract much more developers from *nix to ReactOS (I mean user side applications).
If we continue with Visual Studio support, we would attract far more developers to ReactOS, since there are far more Windows-oriented developers who understand a Windows-like operating system, than *nix-oriented developers who understand a Windows-like operating system.
Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: Why Not Use "Cl.exe Link.exe" as the primary compiler?

Post by Z98 »

Amine is looking into the issue, though he would like to know if you are using the cmake we distribute or the vanilla cmake.

Regarding C11, its improvements are for the most part irrelevant to us. To support its newer, higher level functionality, your operating system has to provide a certain level of infrastructure. Since we're writing the OS, that infrastructure isn't there. As such, we wouldn't be able to use the new stuff anyway.

Also, we don't have a pressing need for user applications. The entire software world has done a pretty damn good job producing software for Windows already.
BlackRabbit
Posts: 128
Joined: Sat Dec 22, 2012 7:36 am

Re: Why Not Use "Cl.exe Link.exe" as the primary compiler?

Post by BlackRabbit »

Z98 wrote:Amine is looking into the issue, though he would like to know if you are using the cmake we distribute or the vanilla cmake.
I am using the one that I got from Amine, in fact:

[ external image ]
hbelusca
Developer
Posts: 1197
Joined: Sat Dec 26, 2009 10:36 pm
Location: Zagreb, Croatia

Re: Why Not Use "Cl.exe Link.exe" as the primary compiler?

Post by hbelusca »

Hi all !

It's the first time I'm testing compilation of ReactOS via Visual Studio (the IDE of course).

I have two remarks:
- I can correctly find the definition of the NtSetSystemPowerState function : it is in ntpoapi.h (see the screen-shot).
- I get the same shell32 linking errors as BlackRabbit.

[ external image ]

(sorry for its big size)
hbelusca
Developer
Posts: 1197
Joined: Sat Dec 26, 2009 10:36 pm
Location: Zagreb, Croatia

Re: Why Not Use "Cl.exe Link.exe" as the primary compiler?

Post by hbelusca »

Amine just tried to fix HAL compilation in revision 58862. Can you retest its compilation please ?
Note that it is a regression, as the boot-cd and the live-cd used to compile fine with Visual Studio IDE (according to Amine).
BlackRabbit
Posts: 128
Joined: Sat Dec 22, 2012 7:36 am

Re: Why Not Use "Cl.exe Link.exe" as the primary compiler?

Post by BlackRabbit »

Done. No more errors on build of HAL.

The only two projects with remaining errors are browseui.dll and shell32.dll:
Visual Studio C++ Express 2010 wrote: ------ Build started: Project: ALL_BUILD, Configuration: Debug Win32 ------
Build all projects
========== Build: 29 succeeded, 2 failed, 762 up-to-date, 0 skipped ==========
Post Reply

Who is online

Users browsing this forum: DotBot [Crawler], Semrush [Bot] and 2 guests