Hi,
today i tried to compile ReactOS with gcc 4.1.2 under RosBE 0.3.4
(previously i used both gcc 3.4.5 and gcc 4.1.2, with a previous svn
revision).
Before trying to switch compilers i have successfully built an iso
image with gcc 3.4.5. So, i issued a make clean in the gcc 3.4.5
enviroment. Then i changed to gcc 4.1.2 and issued a make bootcd (with
current SVN). In the building process i got this error message:
[CC] lib\intrlck\i386\compareexchange.c
[AR] obj-i386\lib\intrlck\intrlck.a
[LD] output-i386\dll\ntdll\ntdll.dll
[RSYM] output-i386\dll\ntdll\ntdll.dll
[LD] output-i386\dll\win32\kernel32\kernel32.dll
obj-i386\dll\win32\kernel32\misc\dllmain.o: In function
`InterlockedCompareExchange@12':
d:/reactos/current/include/psdk/intrin.h:110: undefined reference to
`__sync_val_compare_and_swap_4'
obj-i386\dll\win32\kernel32\misc\dllmain.o: In function
`InterlockedIncrement@4':
d:/reactos/current/include/psdk/intrin.h:139: undefined reference to
`__sync_fetch_and_add_4'
obj-i386\dll\win32\kernel32\misc\dllmain.o: In function
`InterlockedDecrement@4':
d:/reactos/current/include/psdk/intrin.h:139: undefined reference to
`__sync_fetch_and_add_4'
obj-i386\dll\win32\kernel32\misc\dllmain.o: In function
`InterlockedExchangeAdd@8':
d:/reactos/current/include/psdk/intrin.h:139: undefined reference to
`__sync_fetch_and_add_4'
collect2: ld returned 1 exit status
mingw32-make: *** [output-i386\dll\win32\kernel32\kernel32.dll] Error 1
I'm using ReactOS Build Environment 0.3.4-4.1.2-20061229-prerelease-patched.
Probably i could comment the gcc version checking in intrin.h to get
this to compile, but that isn't nice/right :P.
As far as i know __sync_* functions are supplied by the compiler and
they should be present in gcc 4.1.2. Is this right?
Anyone got an idea why this doesn't work?
Thanks in advance for your help,
Best regards,
Logan_V8
d:\reactos\current>echo __GNUC__ * 10000 + __GNUC_MINOR__ * 100 +
__GNUC_PATCHLEVEL__ > p.txt
d:\reactos\current>cpp < p.txt
cc1.exe: warning: is shorter than expected
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "<stdin>"
4 * 10000 + 1 * 100 + 2
fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Thu Feb 1 01:30:59 2007
> New Revision: 25667
>
> URL: http://svn.reactos.org/svn/reactos?rev=25667&view=rev
> Log:
> - Comment out clearing of KeLoaderBlock (introduced by 25629), because it looks like someone is still calling IopLoadServiceModule() even after that point. 2nd stage boots with this change.
>
This does not fix the freeze/slowdown/issue I am seeing with the NT
scheduler disabled. I still can't boot to desktop.
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Thu Feb 1 01:30:59 2007
> New Revision: 25667
>
> URL: http://svn.reactos.org/svn/reactos?rev=25667&view=rev
> Log:
> - Comment out clearing of KeLoaderBlock (introduced by 25629), because it looks like someone is still calling IopLoadServiceModule() even after that point. 2nd stage boots with this change.
>
>
I still get a hang after pressing "Next" on the last 2nd stage setup
wizard page.
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
Hi,
A few weeks ago, I received an e-mail asking me to test Burn, my old
drawing-program for Dos, on ReactOS. However, I've lost that e-mail
somehow, so I'm hoping this mailinglist is the right place to send my
reply, as a substitute. The original e-mail was from someone
affiliated with ReactOS.
I used ReactOS 0.3-RELEASE (Build 20060827-r23747), running under Qemu.
A screenshot of how it went is included. ("Bad command or filename",
even though the command was valid). Burn works perfectly well under
DosBox.
Hope this was of any help whatsoever, and thanks for your
contributions to the world of open source.
Best regards,
Alexander Rødseth
> Can't really fix this, this is a side effect of
> the fact that NT checks that the initial boot
> process didn't die, and the fact that our setup
> code actually replaces the initial process.
It can be fixed on process level, not on the kernel level.
