Hi all !
ReactOS severely needs to be self-hostable for many reasons, one of it because it could allow people who only have Linux to be able to program / debug ReactOS with Windows tools (e.g. we have some people here and there complaining that they cannot use powerful debugging programs for debugging ReactOS (e.g. WinDbg and so on with MSVC builds of ReactOS) and therefore restrain themselves in using the Goode Olde GCC + DPRINT method, because they are running only on Linux). Something more personal is that I really want to program ReactOS on itself (in a VM) when it becomes self-hostable. But there are *only* few steps remaining before ReactOS can really be in such situation !!
Ive already tested RosBE on it and I was able to download and configure a build. But there *are still* problems.
Here is my setup on a VM: main HDD of letter drive C: with ReactOS, second HDD of letter drive D: with ROS source code in D:\rossrc, third HDD of letter drive E: with build output files in E:\rosbuild .
After having successfully configured a build in the usual way (E:\rosbuild> D:\rossrc\configure.cmd), I first tried to compile the host-tools (cd host-tools && ninja). The first thing that Ive noticed is that doing so retriggered a configure, then the compilation as wanted. I retried again, and again it reconfigured the build before actually rebuilding the host-tools. The same phenomenon appears then when trying to build ReactOS proper.
After analyzing produced files by the configuration step and comparing with a clean build on windows 2k3, it became clear that few files were missing, because obviously not generated:
E:\rosbuild\host-tools\CMakeFiles\2.8.10.2-ReactOS\CMakeCCompiler.cmake and CMakeCXXCompiler.cmake . The other .cmake files that should also be present here (CMakeRCCompiler.cmake and CMakeSystem.cmake) as well as two .bin files and two subdirectories where present (and contain the same things).
I was suggesting it might be a problem with the command-line interpreter, so I changed our cmd.exe with the one of windows 2000 (not win2k3, because the latter makes extra calls to some security APIs of advapi32 not implemented on ReactOS before running .bat / .cmd files, and it fails), but nothing changed, the files were not still present.
After having enabled extra debug output of cmake (that is called when configuring a build) by adding the flags --debug-output --trace (without quotes) in the cmake calls in configure.cmd (and after redirecting console stdout + stderr to a file when retrigerring a clean configuration), doing that on ReactOS *and* on win2k3 for comparison purposes, I saw that, at some point, some cmake flags concerning compiler recognition (à la: CMAKE_GCC_EXISTS for example) werent set to TRUE or FALSE, but were kept empty.
So Im wondering whether it is actually some issue, either concerning our C runtime library (e.g. some called sprintf-like function fails or whatever) is buggy and something fails, OR, something file-system related. Concerning file-system, you know that we have LOTS of kernel32:file winetests failing, about problems for deleting files, recreating (or just creating) them, and so on Maybe for some reason cmake fails to create those CMake(C/CXX)Compiler.cmake files for the same reason one of the kernel32:file tests fail ?
I dont know, this previous point being speculative since I didnt test anything regarding that.
Therefore it would be very nice *to see you all* trying to uncover where this bug comes from so that you can *finally* declare ReactOS self-hostable before, maybe, the next release !!
Cheers,
Hermès
14.03.2014 00:53, Hermès BÉLUSCA - MAÏTO пишет:
Hi all !
ReactOS severely needs to be self-hostable for many reasons, one of it because it could allow people who only have Linux to be able to program / debug ReactOS with Windows tools (e.g. we have some people here and there complaining that they cannot use powerful debugging programs for debugging ReactOS (e.g. WinDbg and so on with MSVC builds of ReactOS) and therefore restrain themselves in using the “Goode Olde” GCC + DPRINT method, because they are running only on Linux). Something more personal is that I really want to program ReactOS on itself (in a VM) when it becomes self-hostable. But there are **only** few steps remaining before ReactOS can really be in such situation !!
I’ve already tested RosBE on it and I was able to download and configure a build. But there **are still** problems.
Here is my setup on a VM: main HDD of letter drive C: with ReactOS, second HDD of letter drive D: with ROS source code in D:\rossrc, third HDD of letter drive E: with build output files in E:\rosbuild .
After having successfully configured a build in the usual way (E:\rosbuild> D:\rossrc\configure.cmd), I first tried to compile the host-tools (cd host-tools && ninja). The first thing that I’ve noticed is that doing so retriggered a configure, then the compilation as wanted. I retried again, and again it reconfigured the build before actually rebuilding the host-tools. The same phenomenon appears then when trying to build ReactOS proper.
After analyzing produced files by the configuration step and comparing with a clean build on windows 2k3, it became clear that few files were missing, because obviously not generated:
E:\rosbuild\host-tools\CMakeFiles\2.8.10.2-ReactOS\CMakeCCompiler.cmake and CMakeCXXCompiler.cmake . The other .cmake files that should also be present here (CMakeRCCompiler.cmake and CMakeSystem.cmake) as well as two .bin files and two subdirectories where present (and contain the same things).
I was suggesting it might be a problem with the command-line interpreter, so I changed our cmd.exe with the one of windows 2000 (not win2k3, because the latter makes extra calls to some security APIs of advapi32 – not implemented on ReactOS – before running .bat / .cmd files, and it fails), but nothing changed, the files were not still present.
After having enabled extra debug output of cmake (that is called when configuring a build) by adding the flags “--debug-output --trace” (without quotes) in the cmake calls in configure.cmd (and after redirecting console stdout + stderr to a file when retrigerring a clean configuration), doing that on ReactOS **and** on win2k3 for comparison purposes, I saw that, at some point, some cmake flags concerning compiler recognition (à la: “CMAKE_GCC_EXISTS” for example) weren’t set to TRUE or FALSE, but were kept empty.
So I’m wondering whether it is actually some issue, either concerning our C runtime library (e.g. some called sprintf-like function fails or whatever) is buggy and something fails, OR, something file-system related. Concerning file-system, you know that we have LOTS of kernel32:file winetests failing, about problems for deleting files, recreating (or just creating) them, and so on… Maybe for some reason cmake fails to create those CMake(C/CXX)Compiler.cmake files for the same reason one of the kernel32:file tests fail ?
I don’t know, this previous point being speculative since I didn’t test anything regarding that.
Therefore it would be very nice **to see you all** trying to uncover where this bug comes from so that you can **finally** declare ReactOS self-hostable before, maybe, the next release !!
Cheers,
Hermès
Hello. Thanks for sharing. That problem is urgent for me. I will certainly take a look on it, if I have an opportunity to work on ReactOS more closely.
Hi !
Today Sylvain and me achieved to compile some bits of ReactOS with RosBE 2.1.1. Contrary to what happened with RosBE 2.1, the new RosBE version does not retrigger a full build configuration each time one invokes “ninja”, even if the CMakeCCompiler.cmake and CMakeCXXCompiler.cmake files are not created (at least in my case, because it seems that Sylvain sees them). So that’s nice!
In other words I was able to fully compile the host-tools and e.g. compile the kernel, and other things.
Originally I wanted to directly compile a bootcd, however one cannot compile correctly “libusbd” (manual command: ninja libusbd) because dlltool.exe systematically wants to read at address 0x0C000007, therefore inducing a page fault. I don’t know why, something on ReactOS (or on dlltool) is broken, whatever… and therefore because of that no bootcd can be created with GCC/RosBE yet. BUT, I repeat, one can compile other submodules. That’s a big step!!
David Quintana and Giannis started to have a look at installing MSVC on ReactOS in order to try to see whether it is possible to use MSVC on ReactOS for compiling itself. They currently block on installing it properly without installing too much things (e.g. the unneeded .net framework). So that they could use MSVC builds, and use WinDbg in ReactOS to debug user-mode apps (after replacing ours (read: Wine’s) riched20.dll with Win2k3’s one).
For my side I’ve already configured a build environment on ReactOS, with RosBE 2.1.1 installed on C:\RosBE, the ReactOS sources in D:\rossrc and the output build files going into E:\rosbuild . I modified RosBE.cmd in order it to launch Far Manager in the current directory (at the end of the build environment configuration) with the adequate command. So that I’m able to browse the source files and view/edit them in the same (console) window. By the way, commit 62500 http://svn.reactos.org/svn/reactos?view=revision http://svn.reactos.org/svn/reactos?view=revision&revision=62500 &revision=62500 was my first one using SVN from RosBE in ReactOS :D
I could use Notepad++, version 6.5.x (in fact I use it on my host OS), however it hangs on ReactOS when one quits it, and sometimes puts the CPU usage to 100% for whatever reason (this problem also happens when trying to play with the “Open” dialog box when trying to open a file in Notepad++).
I personally think we can start programming ReactOS *inside* ReactOS, i.e. beginning to self-host ourselves, because globally we are in better shape than Microsoft was when they started to self-host NT: before their devs were developing NT on OS/2, and after their first shift to full NT (command line) it was very painful, especially the first weeks and months (after they switched to GUI, then added network) (see Showstopper!).
For ReactOS devs it can be a really boost for fixing bugs in ReactOS, either in the UI or in some more core parts of the OS.
Have fun!
Hermès.
De : ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] De la part de Alexander Varnin Envoyé : vendredi 14 mars 2014 11:47 À : ros-dev@reactos.org Objet : Re: [ros-dev] ReactOS needs to be self-hostable!
Hello. Thanks for sharing. That problem is urgent for me. I will certainly take a look on it, if I have an opportunity to work on ReactOS more closely.
-
Alexander Varnin -
Hermès BÉLUSCA - MAÏTO