[CORE-4937] Reactos doesn't build on itself Created: 2010-05-24  Updated: 2017-08-15  Resolved: 2017-08-15

Status: Closed
Project: Core ReactOS
Component/s: None
Fix Version/s: None

Type: Story Priority: Major
Reporter: usurp Assignee: ThFabba
Resolution: Duplicate Votes: 8
Labels: METABUG
Environment:

Operating System: ReactOS
Platform: x86 Hardware


Attachments: PNG File 0-3-17RC2_RosBE_nonspaces.png     PNG File 0-3-17RC2_RosBE_spaces.png     Text File 0.4.6RC1-vs-RosBE2.1.5-ninjaFailed.txt     PNG File 0.4.6RC1-vs-RosBE2.1.5_1_configureSucceed.png     PNG File 0.4.6RC1-vs-RosBE2.1.5_2_ninjaFailed.png     File RosBE_manual_command_execute.log     PNG File bootcd-74189-dbg-RosBE.2.1.4.png     Text File bug_ninja_rosbe_reactos.txt     File ninja.exe     Text File rbuild_workaround.diff    
Issue Links:
Blocks
is blocked by CORE-6335 win32k: Assertion 'Hash == TableMask'... Resolved
is blocked by CORE-3979 Changes made to PAGE_WRITECOPY file m... Resolved
is blocked by CORE-6646 Command line svn fails to checkout re... Resolved
is blocked by CORE-6710 crt: strftime / _tcsftime are unimple... Resolved
is blocked by ROSBE-112 RosBE 2.1.4 i386 contains x64 executa... Resolved
Duplicate
duplicates CORE-13683 Make it possible to build ReactOS on ... Resolved
Relates
relates to CORE-7870 Problem compiling host-tools with Ros... Resolved
relates to CORE-11952 Building ReactOS under itself: confi... Resolved
External URL: http://www.reactos.org/bugzilla/show_bug.cgi?id=5424
External issue ID: 5424

 Description   

ReactOS should be able to be built on itself, but can't be done atm.

Workarounds needed to get a partial build :
-Disable precompiled headers use in rbuild options (CORE-3979)

-Patch rbuild to avoid an fstat problem (invalid file date detected).

-Use "make -j 1 -k" as build command.
avoids deadlocks (ros is single core atm) and keeps going when getting ERROR_INVALID_NAME
(CORE-3284)



 Comments   
Comment by usurp [ 2010-05-24 ]

Created an attachment (id=5092)
Rbuild invalid date patch

Comment by usurp [ 2010-05-24 ]

Attachment rbuild_workaround.diff has been added with description: Rbuild invalid date patch

Comment by usurp [ 2010-05-30 ]

(In reply to comment #0)
> -Patch rbuild to avoid an fstat problem (invalid file date detected).
After investigation, there is no fstat problem.
Using a different locale than english can give you a wrong time at the clock,
making your files apppear modified in the future (which is the purpose of the invalid date rbuild test.)

Before building : make sure your clock is correct.

Comment by usurp [ 2010-05-30 ]

Current status : builds and installs fine if quartz & quartz_winetest are disabled.
(gcc internal crash occurs when building quartz.)

Comment by usurp [ 2012-09-28 ]

In order to make the getdate tool to work,
strftime has to be implemented.

If the date is forced to the fallback result,
a ninja build can be completed.

Rostests & rosapps build fine,
so do bootcdregtest and livecd.

Comment by hbelusca [ 2012-12-18 ]

Hi Sylvain ! Can you retest with the newest changes both in ReactOS trunk and the new RosBE ? Thanks

Comment by usurp [ 2012-12-21 ]

Assertion 'Hash == TableMask' failed at ../../ntoskrnl/mm/ARM3/expool.c line 573 is triggered at configure step.

Comment by hbelusca [ 2012-12-26 ]

With the very latest RosBE 2.1rc1 Amine Edition from http://svn.reactos.org/amine/RosBE-2.1.exe , you need to use ReactOS revision >= 58016.

Comment by hbelusca [ 2012-12-26 ]

Now, checking out all the ReactOS source tree from ReactOS itself with SVN, works without having corrupted / interrupted downloads.

Comment by hbelusca [ 2012-12-26 ]

Configuring build with 'configure Ninja' works correctly.

Comment by hbelusca [ 2012-12-26 ]

Sometimes, some
Assertion '(LastEntry + LastEntry->Size) == FirstEntry' failed at C:/Users/ReactOS/trunk/reactos/lib/rtl/heap.c line 675
are triggered during using SVN.

Comment by usurp [ 2013-03-23 ]

Before r58564, the bootcd build triggered a MoveFileEx bug, because hive files were renamed to themselves.
It appears as todo_wine in kernel32:file test.
600 ret = MoveFileA(source, source);
601 todo_wine ok(ret, "MoveFileA: failed, error %d\n", GetLastError());

Comment by hbelusca [ 2014-09-11 ]

Compiling usbhub library with RosBE 2.1.1 Ninja on ReactOS revision 63968 fails, because dlltool crashes for an obscure reason:

Entered debugger on first-chance exception (Exception Code: 0xc0000005) (Page Fault)
Memory at 0x0C000007 could not be read: Page not present.
kdb:> bt
Eip:
<dlltool.exe:15eb>
Frames:
<dlltool.exe:93818>
<dlltool.exe:13f5>
<KERNEL32.dll:fb73>
<00000000>
kdb:> cont
Unhandled exception
ExceptionCode:    c0000005
Faulting Address:  c000007
CS:EIP 1b:4015eb
DS 23 ES 23 FS 3b GS 0
EAX: 0003ae74   EBX: 0003ae6c   ECX: 0c000007
EDX: 000364c8   EBP: 010cfe38   ESI: 004015e0   ESP: 010cfe00
EDI: 0003ae74   EFLAGS: 00010216
Address:
     400000+15eb       C:\ROSBE\i386\bin\dlltool.exe
Frames:
     400000+9381d      C:\ROSBE\i386\bin\dlltool.exe
     400000+13fa       C:\ROSBE\i386\bin\dlltool.exe
   77d80000+fb78       C:\ReactOS\system32\KERNEL32.dll

Since I don't have the source of dlltool there, I IDA'ed the dlltool executable that was used. Here are my findings (the base of dlltool is 0x400000):
The function @ 0x13fa is the entry point function.
At 0x9381d there is the following:

.text:00493801 loc_493801:                             ; CODE XREF: main__+7BEj
.text:00493801                 mov     [esp+8Ch+var_88], eax
.text:00493805                 mov     [esp+8Ch+var_80], offset FuncCompare
.text:0049380D                 mov     [esp+8Ch+var_84], 4
.text:00493815                 mov     [esp+8Ch+var_8C], esi
.text:00493818                 call    qsort
.text:0049381D                 mov     eax, ds:dword_4BD028
.text:00493822                 cmp     eax, 1
.text:00493825                 jg      loc_493978
.text:0049382B
 
// Decompilation
void *v29; // esi@67
size_t v33; // eax@70
[...]
    qsort(v29, v33, 4u, (int (__cdecl *)(const void *, const void *))FuncCompare);
    v33 = dword_4BD028;
    if ( dword_4BD028 <= 1 )
      break;

And offset 0x15eb is at the beginning of the FuncCompare function:

.text:004015E0 FuncCompare     proc near               ; DATA XREF: main__+555o
.text:004015E0                                         ; main__+884o
.text:004015E0
.text:004015E0 arg_0           = dword ptr  4
.text:004015E0 arg_4           = dword ptr  8
.text:004015E0
.text:004015E0                 push    ebx
.text:004015E1                 mov     eax, [esp+4+arg_0]
.text:004015E5                 mov     ecx, [eax]
.text:004015E7                 mov     eax, [esp+4+arg_4]
.text:004015EB                 mov     ebx, [ecx]
.text:004015ED                 mov     ecx, [ecx+0Ch]
.text:004015F0                 mov     eax, [eax]
.text:004015F2                 test    ecx, ecx
.text:004015F4                 mov     edx, [eax]
 
// Decompilation
int __cdecl FuncCompare(const char *Str1, const char *Str2)
{
  const char *v2; // ecx@1
  const char **v3; // eax@1
  const char *v4; // edx@1
  const char *v5; // eax@2
 
  v2 = *(const char **)(*(_DWORD *)Str1 + 12);
  v3 = *(const char ***)Str2;
  v4 = (const char *)**(_DWORD **)Str2;
  if ( v2 )
  {
    v5 = v3[3];
    if ( v5 )
      goto LABEL_3;
  }
  else
[...]

So I don't know.... Maybe qsort calls the comparison function with invalid parameters at some point?

Comment by ThePhysicist [ 2014-09-12 ]

source code:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=binutils/dlltool.c

Comment by Black_Fox [ 2014-10-22 ]

Tried on 0.3.17RC2.
Build fails sooner if source lies in path with spaces, but otherwise it fails on windres, attaching screenshots.

Comment by Black_Fox [ 2015-06-25 ]

r68263, still there.

EDIT: Exact same issues as in my previous comment.

Comment by hbelusca [ 2015-06-25 ]

Nothing was indeed changed so far in this area, so yes, still there.

Comment by Jedi-to-be [ 2015-09-05 ]

New BE, any changes?

Comment by encoded [ 2015-11-19 ]

Someone needs to change the bug description.. rbuild is not relevant anymore.. provide some sort of description of the current problem..

Comment by Swyter [ 2015-11-20 ]

I attempted to build a bootcd the other day in ReactOS TRUNK by using the latest RosBE.

Things to keep in mind, the batch scripts like ssvn don't work correctly, one has to call svn co <repo url> manually, SVN gets stuck from time to time in the download process, the command has to be killed and the checkout resumed by using svn up. Didn't finish, the guest input locked up half way.

Someone should try to reach to the configure.cmd and cd output-...\reactos && ninja bootcd phase. In theory running cmake, ninja and gcc should work just fine.

Comment by Black_Fox [ 2015-11-20 ]

Well, you can see from the attached screenshots that exactly that point can be reached, but compilation doesn't finish. The screens are from 0.3.17 RCs but last time I tried on r68263, it didn't change.

Comment by Swyter [ 2015-11-20 ]

I see, seems like almost all of the build problems are related with the command line parser and interpreter, including those located in batch files. Seeing that the build environment is almost totally based around scripts I see why this might take a while.

In the case of those screenshots I would try to checkout the source code directly in C: to avoid spaces in paths.

Edit: Now I see that you already tried that and gives you an error in windres. Damn JIRA hiding older comments.

Comment by ariscop [ 2015-11-27 ]

In current trunk, cmake works (albeit incredibly slowly) but when running ninja build commands randomly fail

Comment by hbelusca [ 2015-11-27 ]

You're right, it works very slowly (and iirc the CPU is at 100%), and (unless it was mysteriously fixed) it usually wants to rerun full build configures each time you do a ninja <put_your_target_here>

Comment by Tim [ 2016-06-09 ]

(ntoskrnl/mm/i386/page.c:768) Bad PTE 1307b
 
*** Fatal System Error: 0x0000001a
                       (0x00000000,0x00000000,0x00000000,0x00000000)
 
 
Entered debugger on embedded INT3 at 0x0008:0x8093f9dc.
kdb:> bt
Eip:
<NTOSKRNL.EXE:13f9dd (:0 (RtlpBreakWithStatusInstruction))>
Frames:
<NTOSKRNL.EXE:81dbd (ntoskrnl/ke/bug.c:1100 (KeBugCheckWithTf))>
<NTOSKRNL.EXE:823cd (ntoskrnl/ke/bug.c:1472 (KeBugCheck))>
<NTOSKRNL.EXE:127a15 (ntoskrnl/mm/i386/page.c:769 (MmCreateVirtualMappingUnsafe))>
<NTOSKRNL.EXE:127ba7 (ntoskrnl/mm/i386/page.c:809 (MmCreateVirtualMapping))>
<NTOSKRNL.EXE:932d (ntoskrnl/cc/view.c:629 (CcRosGetVacb))>
<NTOSKRNL.EXE:982b (ntoskrnl/cc/view.c:852 (CcRosRequestVacb))>
<NTOSKRNL.EXE:5a15 (ntoskrnl/cc/pin.c:69 (CcMapData))>
<NTOSKRNL.EXE:5e36 (ntoskrnl/cc/pin.c:174 (CcPinRead))>
<fastfat.sys:5e0d>
<fastfat.sys:62c4>
<fastfat.sys:3005>
<fastfat.sys:dd24>
<fastfat.sys:e33b>
<NTOSKRNL.EXE:6b77b (ntoskrnl/io/iomgr/irp.c:1221 (IofCallDriver))>
<NTOSKRNL.EXE:5fc46 (ntoskrnl/io/iomgr/file.c:861 (IopParseDevice))>
<NTOSKRNL.EXE:f3cfb (ntoskrnl/ob/obname.c:809 (ObpLookupObjectName))>
<NTOSKRNL.EXE:ec96c (ntoskrnl/ob/obhandle.c:2531 (ObOpenObjectByName))>
<NTOSKRNL.EXE:610a0 (ntoskrnl/io/iomgr/file.c:2466 (IoCreateFile))>
<NTOSKRNL.EXE:61d83 (ntoskrnl/io/iomgr/file.c:3223 (NtCreateFile))>
<NTOSKRNL.EXE:1252e4 (ntoskrnl/include/internal/i386/ke.h:706 (KiSystemServiceHandler))>--- Press q to abort, any other key to continue ---
 
<NTOSKRNL.EXE:3da9 (:0 (KiFastCallEntry))>
<ntdll.dll:c81d>
<MSVCR120.dll:7e6c1>
<cmake.exe:1f9d04>
<109c4338>
<cmake.exe:1f09bb>
<ffffc648>
Couldn't access memory at 0xE8F18B5A!
kdb:> cont
(ntoskrnl/ke/bug.c:602) Potentially unloaded driver!
(ntoskrnl/ke/bug.c:602) Potentially unloaded driver!
(ntoskrnl/ke/bug.c:602) Potentially unloaded driver!
(ntoskrnl/ke/bug.c:602) Potentially unloaded driver!
 
Entered debugger on embedded INT3 at 0x0008:0x8093f9dc.

Official 71595 GCC ISO
RosBE 2.1.3 from rapps
I've hit this bugcheck a few times when running configure.cmd.

Comment by reactosfanboy [ 2016-10-24 ]

r72998: VBox4.3.40,1000MB RAM, I tried without any additional workarounds mentioned in the tickets description, just RosBE 2.1.3 out of the box:

svn checkout svn://svn.reactos.org/reactos/trunk/reactos 

worked,

configure

was running for about 5minutes when it started to spam

(../ntoskrnl/mm/ARM3/pfnlist.c:632) Legacy Mm eating ARM3 page!

after a minute of that spam the system was frozen -> failed

Comment by hbelusca [ 2016-10-24 ]

Cc zefklop and ThFabba for the Mm problem: is it possible that the Mm spam is due somewhat to a leak in ROS? As I guess the build configure step is very FS-intensive, maybe a problem in fastfat?

Comment by Jedi-to-be [ 2017-03-19 ]

r74189

error on configure comand, see screnshot

Comment by Jedi-to-be [ 2017-03-19 ]

i got this after attempt of ninja.exe (from RosBE 2.1.4 from RAPPS) .execution

ERROR BAD EXE FORMAT not valid win32 application

fixme:(dll/win32/shell32/shlexec.cpp:1782) flags ignored: 0x00000004
(dll/win32/kernel32/client/proc.c:3532) Failed to create section: c000007b
WARNING: MmUnlockPageableImageSection at ntoskrnl/mm/ARM3/drvmgmt.c:39 is UNIMPLEMENTED!
(win32ss/user/ntuser/message.c:1256) err: UserPostMessage: Invalid handle 0xBC6502C4 Msg 0x2a3!

Comment by Jedi-to-be [ 2017-03-19 ]

The same ninja.exe taken from ReactOS VHD starts normaly in Windows 7

Comment by Jedi-to-be [ 2017-03-19 ]

Later i have took older version of ninja.exe from my computer (probably RosBE 2.1.3 of 2015 year) and it worked in ReactOS!

Comment by hbelusca [ 2017-03-19 ]

So for me, it looks like this (new version?) of ninja was compiled for Windows Vista+. EmuandCo, can you please check this?

Comment by hbelusca [ 2017-03-19 ]

Jedi-to-be: In the meantime, try to continue using RosBE 2.1.3 (still exists on sourceforge).

Comment by EmuandCo [ 2017-03-19 ]

Here is a ninja for you. It does not work on ROS due to MM problems anyway yet and XP is not really a reason to release another new RosBE just to downgrade to an older ninja. Try mingw32-make which is included too

Comment by Jedi-to-be [ 2017-03-19 ]

how to use mingw32-make?

Comment by EmuandCo [ 2017-03-19 ]

Use ninja by overwriting the current one. Make is not working right now https://jira.reactos.org/projects/ROSBE/issues/ROSBE-80

I tried my luck with building my own one. Maybe it works for ya. This is a v1.7.2 too.

Comment by Mark Jansen [ 2017-03-20 ]

The ninja in RosBE is a 64 bits file,
as well as the minimal operating system required is set to '6.0'

Comment by EmuandCo [ 2017-03-20 ]

Well. Ooops. ^^ Did someone try the one I posted?

Comment by Jedi-to-be [ 2017-03-20 ]

Daniel probably we need rosbee 2.1.5

Comment by EmuandCo [ 2017-03-20 ]

We dont need anything. RosBE works and unless someone gives me a reason aka confirms my stuff working, I wont add/release anything.

Comment by hbelusca [ 2017-03-20 ]

Just compiling the RosBE stuff for x86 (not x64) and specifying the (Windows) subsystem version 5.1 (linker options) should be what's needed to have RosBE stuff usable on Windows XP/2k3+ and on ROS.

Comment by amber [ 2017-03-21 ]

RosBE compiles a 32 bit operating system. Why do we need 64 bit support if 64 bit Windows can run 32 bit compilers or not? Can then make conditional compilation? If x32 then... else...

Comment by Mark Jansen [ 2017-03-21 ]

Guys, who are you trying to convince?
Just try the file on ReactOS and report the result...

EmuandCo: This seems to be a 32 bit file, and from inspecting the file header it could run on reactos.
However it seems to be linked weird, since there is a .CRT section (and this is usually not the case, as the linker collapses it in another section)

Comment by EmuandCo [ 2017-03-21 ]

Thx for the first useful entry after a while. (except HBelusca's ^^) This was built with RosBE 2.1.4 Windows and a tarball of NINJA + stripping in the end.

If we continue with useless discussion and noone trying out SOLUTIONS I posted, I will close this one was WONTFIX! You are the ones with problems, not me/us, so test it!

Comment by EmuandCo [ 2017-03-22 ]

Noone tested it, so... I did. ReactOS likes it and thus this is the temporary workaround. Next release (nope, not two years of waiting again) will include it + the PATH var fix

Comment by reactosfanboy [ 2017-05-06 ]

retested 0.4.5RC2 with RosBE2.1.4: VBox4.3.40,1000MB RAM:
'SSVN create' failed with 'The selected branch does not exist or the internet connection is down.' nothing in log > I used svn checkout svn://svn.reactos.org/reactos/trunk/reactos instead - worked, why does it fail? ROSBE-84 & ROSBE-88 are in fixed state. Later x64 ninja stuff...

Comment by hbelusca [ 2017-05-08 ]

Good news with RosBE 2.1.4 and x86 ninja, running on ReactOS 0.5-SVN r74509 MSVC: The initial configuration step works OK, then doing a ninja <somemodule> works directly (without any erroneous re-configuration step, as it occurred some time ago).

Comment by hbelusca [ 2017-05-08 ]

However for whatever reason, it is claimed that "Command or file name unknown - C:\RosBE\i386\bin\ar.exe" when trying to compile different modules. See the bug_ninja_rosbe_reactos.txt log for more details.
My test setup is:

  • RosBE installation in C:\RosBE ,
  • Source code in D:\rossrc ,
  • Output build directory in E:\rosbuild.
    The build configuration: E:\rosbuild> D:\rossrc\configure.cmd went completely without any error.
    On Windows, such a setup works fully OK.
Comment by Swyter [ 2017-05-09 ]

hbelusca: Maybe it has to do with how the different commands are conditionally chained with && in a big string. As far as I remember, the ReactOS cmd doesn't handle very well unorthodox batch scripts, having problems with things like call's, functions and goto's. In this case CMake seems to be inlining an awful lot of complexity in a single place, which may cause parser pitfalls. Just a guess.

Comment by hbelusca [ 2017-05-09 ]

I don't know. But I know it worked few months ago...

Comment by A_S [ 2017-07-06 ]

I try to reproduce HBelusca's expiriment on r75275. Before it I compile Ninja 1.7.2 on ReactOS from source using Python 3.4.3 and minGW from RosBE . Then I replace original ninja.exe and try to compile ntvdm module. I notice the following:

  1. Build configuration is very slow and took ~900 Mb of memory. Possible ninja.exe too large (~5 Mb)?
  2. Build fails if command contains double spaces (it was reported before).
  3. If I remove double space and try to execute the command in RosBE prompt cmd.exe fails with Memory write error in most cases and one time I get a system hang. Also a debug log ( RosBE_manual_command_execute.log ) contains strange messages from NTFS driver like this:

    (drivers/filesystems/ntfs/create.c:256) NtfsOpenFile(B49354E8, B44AD7A0, \ReactOS\ReactOS-0.4.5-src\dbghelp\CMakeFiles\dbghelphost.dir\cpu_i386.c.obj && C:\RosBE\i386\bin\ranlib.exe dll\win32\dbghelp\libdbghelphost.a && cd .", F6B2F950)
    

Comment by hbelusca [ 2017-07-06 ]

Hello A_S, thanks for testing this, too. The fact you get NTFS messages seems to be because you're using a NTFS drive somewhere in your ReactOS config? But anyways, the fact that it shows up a full cmd.exe command line (with the "&&" command separator) certainly shows that for some reason, cmd.exe was unable to cut out the different commands & filenames before asking (e.g.) some other command or CreateFile (or whatever else) to try to open such a file.

Comment by A_S [ 2017-07-07 ]

hbelusca, yes I have second drive D:\ formatted in NTFS with programs distributive and ReactOS 0.4.5 source code for this test. RosBe configured to use the sources directly from this drive. Build files saved to C:\build.

UPD: If I copy ReactOS's cmd.exe to WinXP and try to execute ninja ntvdm Windows complains on similar chunks I found in NTFS driver debug output. So, I agree with you: the problem located in cmd parser.

Comment by Mark Jansen [ 2017-07-07 ]

Yes we need to verify cmd commandline parser.
There are some bugs with parsing, and with executing task synchronous / asynchronous.

Comment by Jedi-to-be [ 2017-08-06 ]

Please retest with RosBE 2.1.5 to find if we have new regressions or improvements.
https://sourceforge.net/projects/reactos/files/RosBE-Windows/i386/2.1.5/

Comment by reactosfanboy [ 2017-08-10 ]

0.4.6RC1 VBox4.3.40, 1000MB RAM, RosBE2.1.5 achieved a new personal record:

'SSVN create'
failed with 'The selected branch does not exist or the internet connection is down.'
nothing in log and the cert-update was selected during rosbe-setup.
This bug does not happen on WinXP, so it's a ros bug here not accepting the certs.
workaround: I used 'svn checkout svn://svn.reactos.org/reactos/trunk/reactos' instead.

I restarted ros to free more RAM for consecutive steps here!

'configure'
required up to 800MB RAM in taskmgr and took 30mins but succeeded for the first time for me.
0.4.6RC1-vs-RosBE2.1.5_1_configureSucceed.png
The slowness is not caused by log-spam, cause nothing gets logged.
Recommendation: keep an eye on resource consumption if you are tight on RAM via taskmgr in parallel.

I restarted ros to free more RAM for consecutive steps here!

'ninja bootcd -j1'
failed at [5/9303] with ERROR_PATH_NOT_FOUND 2 message-boxes
0.4.6RC1-vs-RosBE2.1.5_2_ninjaFailed.png
0.4.6RC1-vs-RosBE2.1.5-ninjaFailed.txt ends with the 2entries for each box.

Comment by amber [ 2017-08-10 ]

reactosfanboy: thanks for testing! May to create a separate issue about ERROR_PATH_NOT_FOUND? (and link it with this issue)

Comment by Jedi-to-be [ 2017-08-10 ]

(../../dll/win32/kernel32/client/proc.c:2928) Open file failed: c000003a (\??\C:\ros\reactos\output-MinGW-i386\host-tools\host.dir\storage.c.obj dll\win32\dbghelp\CMakeFiles\dbghelphost.dir\symbol.c.obj dll\win32\dbghelp\CMakeFiles\dbghelphost.dir\type.c.obj dll\win32\dbghelp\CMakeFiles\dbghelphost.dir\cpu_i386.c.obj)
(../../dll/win32/kernel32/client/proc.c:2928) Open file failed: c0000034 (\??\C:\ros\reactos\output-MinGW-i386\host-tools\,0  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32)

Comment by ThFabba [ 2017-08-15 ]

This ticket has become a huge mess. Closing in favor of CORE-13683. Please create each individual problem as a separate ticket in the future, and link it to the epic.

Generated at Mon Nov 19 00:45:35 UTC 2018 using JIRA 7.3.2#73013-sha1:3d53c97478658c0b98b7301c496605f0c91c20aa.