ReactOS needs to be self-hostable!

[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

[Alexander Varnin]

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.

[Hermès BÉLUSCA - MAÏTO]

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(a)reactos.org [mailto:[e-mail]] De la part de
Alexander Varnin
Envoyé : vendredi 14 mars 2014 11:47
À : ros-dev(a)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.