Menu
▾
▴
reactos-kernel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(64) |
Oct
(438) |
Nov
(183) |
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(132) |
May
(466) |
Jun
(366) |
Jul
(392) |
Aug
(31) |
Sep
(18) |
Oct
|
Nov
|
Dec
|
|
From: James T. <jim...@ad...> - 2002-07-09 05:07:27
|
Hi,
Here is the other one, I did not post it.
i386-mingw32-gcc -Wl,--base-file,base.tmp \
-Wl,--entry,_DllMain@12 \
-mdll -Wl,--image-base,0x76090000 \
-o junk.tmp \
../../ole/uuid.o brsfolder.o changenotify.o classes.o clipboard.o
control.o dataobject.o debughlp.o dialogs.o enumidlist.o folders.o iconcache.o
memorystream.o pidl.o shell32_main.o shelllink.o shlmenu.o shellole.o shellord.o
shellpath.o shellstring.o shellreg.o shlexec.o shlfileop.o shlfolder.o shlview.o
shpolicy.o shv_bg_cmenu.o shv_item_cmenu.o systray.o shell32.dll.dbg.o
../../../reactos/dk/w32/lib/ntdll.a ../../../reactos/dk/w32/lib/kernel32.a
../../../reactos/dk/w32/lib/advapi32.a ../../../reactos/dk/w32/lib/gdi32.a
../../../reactos/dk/w32/lib/user32.a ../../../reactos/dk/w32/lib/comctl32.a
../../../reactos/dk/w32/lib/ole32.a ../../../reactos/dk/w32/lib/shlwapi.a
../../../reactos/dk/w32/lib/wine_unicode.a ../../../reactos/dk/w32/lib/libwine.a
shell32_main.o(.text+0x3ece):shell32_main.c: undefined reference to `MapSL@4'
make[1]: *** [shell32.nostrip.dll] Error 1
make[1]: Leaving directory `/scsi/ros/wine/dlls/shell32'
make: *** [shell32] Error 2
MapSL is in wine kernel32 also, Oh yeah, it's part of windows 9x
kernel32.dll too.
James
|
|
From: James T. <jim...@ad...> - 2002-07-09 03:54:38
|
Steven Edwards wrote: > > My bad this is more mingw brokeness that should be > fixed in the currnet win32api package. > ConvertToGlobalHandle is exported by kernel32.dll and > the win32api snapshot we use is out of date. Our > kernel32 also doesnt export this function so I dont > know if it 9x only or what. I have committed a > workaround that will warn if the function gets called. > It should compile now. > > Steven > Hi, Yes it is Windows 9x. Question, is it really important that we keep to a strict NT rev 6 like implementation? Or~ kill two birds with one stone? Keeping in mind of the separation of win32k.sys and gdi32 and kernel32. Just adding code to kernel32 in user space. James |
|
From: James T. <jim...@ad...> - 2002-07-09 03:31:25
|
Steven Edwards wrote: > > You should need -lfl as I think it is the flex import > lib. hrrrmmm odd. Anyway cool that you still have > cross-compileing working. Its something I havent had a > chance to try. > > This MAX_PATH shit is starting to piss me off also. > > Steven Hi, Removing -lfl from the line work as I can tell. I'm using a old Mingw package too, I guess I should update my stuff. James > > --- James Tabor > <jim...@ad...> > wrote: > > Hi, > > I'm using a linux box to build ROS, it looks like > > I'm missing something here. > > I set export ROS_BUILD_WINE = yes, is there anything > > else I need to set to clear > > this problem? > > Thanks, > > James > > > > i386-mingw32-gcc -I../../include -D__REACTOS__ > > -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK > > -I../../../reactos/include/wine -I./ -I../../include > > -pipe -march=i386 -c > > y.tab.c -o y.tab.o In file included from > > wrctypes.h:24, > > from wrc.h:25, > > from ./parser.y:135: > > ../../include/windef.h:152: warning: `MAX_PATH' > > redefined > > > /usr/lib/gcc-lib/i386-mingw32/2.95.3-6/../../../../i386-mingw32/include/stdlib.h:62: > > > > warning: this is the location of the previous > > definition > > > > i386-mingw32-gcc -Wl,--subsystem,console \ > > -Wl,--entry,_mainCRTStartup \ > > -o wrc.nostrip.exe \ > > dumpres.o genres.o lex.ppl.o lex.yy.o newstruc.o > > ppy.tab.o preproc.o readres.o utils.o > > wrc.o writeres.o y.tab.o > > ../../../reactos/dk/w32/lib/wine_unicode.a -liberty > > -lfl > > > /usr/lib/gcc-lib/i386-mingw32/2.95.3-6/../../../../i386-mingw32/bin/ld: > > cannot find -lfl > > make[1]: *** [wrc.nostrip.exe] Error 1 > > make[1]: Leaving directory > > `/scsi/ros/wine/tools/wrc' > > make: *** [wrc] Error 2 > |
|
From: James T. <jim...@ad...> - 2002-07-09 03:29:38
|
Steven Edwards wrote: > > My bad this is more mingw brokeness that should be > fixed in the currnet win32api package. > ConvertToGlobalHandle is exported by kernel32.dll and > the win32api snapshot we use is out of date. Our > kernel32 also doesnt export this function so I dont > know if it 9x only or what. I have committed a > workaround that will warn if the function gets called. > It should compile now. > > Steven > Hi, Yeah, I guess we can add a stub in the kernel32 dll code. Or, just start writing code to support it. James > > > `ConvertToGlobalHandle@4' > > > dplobby.o(.text+0x26e9):dplobby.c: undefined > > reference to > > > `ConvertToGlobalHandle@4' > > > dplobby.o(.text+0x2713):dplobby.c: undefined > > reference to > > > `ConvertToGlobalHandle@4' > > > make[1]: *** [dplayx.nostrip.dll] Error 1 > > > make[1]: Leaving directory > > `d:/ros/wine/dlls/dplayx' > > > make: *** [dplayx] Error 2 > > |
|
From: Steven E. <ste...@ya...> - 2002-07-09 03:06:24
|
You should need -lfl as I think it is the flex import lib. hrrrmmm odd. Anyway cool that you still have cross-compileing working. Its something I havent had a chance to try. This MAX_PATH shit is starting to piss me off also. Steven --- James Tabor <jim...@ad...> wrote: > Hi, > I'm using a linux box to build ROS, it looks like > I'm missing something here. > I set export ROS_BUILD_WINE = yes, is there anything > else I need to set to clear > this problem? > Thanks, > James > > i386-mingw32-gcc -I../../include -D__REACTOS__ > -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK > -I../../../reactos/include/wine -I./ -I../../include > -pipe -march=i386 -c > y.tab.c -o y.tab.o In file included from > wrctypes.h:24, > from wrc.h:25, > from ./parser.y:135: > ../../include/windef.h:152: warning: `MAX_PATH' > redefined > /usr/lib/gcc-lib/i386-mingw32/2.95.3-6/../../../../i386-mingw32/include/stdlib.h:62: > > warning: this is the location of the previous > definition > > i386-mingw32-gcc -Wl,--subsystem,console \ > -Wl,--entry,_mainCRTStartup \ > -o wrc.nostrip.exe \ > dumpres.o genres.o lex.ppl.o lex.yy.o newstruc.o > ppy.tab.o preproc.o readres.o utils.o > wrc.o writeres.o y.tab.o > ../../../reactos/dk/w32/lib/wine_unicode.a -liberty > -lfl > /usr/lib/gcc-lib/i386-mingw32/2.95.3-6/../../../../i386-mingw32/bin/ld: > cannot find -lfl > make[1]: *** [wrc.nostrip.exe] Error 1 > make[1]: Leaving directory > `/scsi/ros/wine/tools/wrc' > make: *** [wrc] Error 2 __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: Steven E. <ste...@ya...> - 2002-07-09 03:04:26
|
My bad this is more mingw brokeness that should be fixed in the currnet win32api package. ConvertToGlobalHandle is exported by kernel32.dll and the win32api snapshot we use is out of date. Our kernel32 also doesnt export this function so I dont know if it 9x only or what. I have committed a workaround that will warn if the function gets called. It should compile now. Steven > > `ConvertToGlobalHandle@4' > > dplobby.o(.text+0x26e9):dplobby.c: undefined > reference to > > `ConvertToGlobalHandle@4' > > dplobby.o(.text+0x2713):dplobby.c: undefined > reference to > > `ConvertToGlobalHandle@4' > > make[1]: *** [dplayx.nostrip.dll] Error 1 > > make[1]: Leaving directory > `d:/ros/wine/dlls/dplayx' > > make: *** [dplayx] Error 2 __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: James T. <jim...@ad...> - 2002-07-09 01:42:03
|
David Kredba wrote: > > From clear cvs co tree I got : > > make -f makefile.ros -C ./../wine/dlls/dplayx > make[1]: Entering directory `d:/ros/wine/dlls/dplayx' > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dpclass > factory.c -o dpclassfactory.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplay.c > -o dplay.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplaysp > .c -o dplaysp.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplayx_ > global.c -o dplayx_global.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplayx_ > main.c -o dplayx_main.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplayx_ > messages.c -o dplayx_messages.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplobby > .c -o dplobby.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c lobbysp > .c -o lobbysp.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c name_se > rver.c -o name_server.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplayx. > dll.dbg.c -o dplayx.dll.dbg.o > gcc -Wl,--base-file,base.tmp \ > -Wl,--entry,_DllMain@12 \ > -mdll -Wl,--image-base,0x76310000 \ > -o junk.tmp \ > ../../ole/uuid.o dpclassfactory.o dplay.o dplaysp.o > dplayx_global.o > dplayx_main.o dplayx_messages.o dplobby.o lobbysp.o name_server.o dplayx. > dll.dbg.o ../../../reactos/dk/w32/lib/ntdll.a > ../../../reactos/dk/w32/lib/kernel32.a ../../../reactos/dk/w32/lib/user32.a > ../../../reactos/dk/w32/lib/ > ole32.a ../../../reactos/dk/w32/lib/libwine.a -lwinmm > dplobby.o(.text+0x26bf):dplobby.c: undefined reference to > `ConvertToGlobalHandle@4' > dplobby.o(.text+0x26e9):dplobby.c: undefined reference to > `ConvertToGlobalHandle@4' > dplobby.o(.text+0x2713):dplobby.c: undefined reference to > `ConvertToGlobalHandle@4' > make[1]: *** [dplayx.nostrip.dll] Error 1 > make[1]: Leaving directory `d:/ros/wine/dlls/dplayx' > make: *** [dplayx] Error 2 > > David > Hi, ConvertToGlobalHandle is in ./wine/dlls/kernel/kernel32.spec. So, in ./reactos/Makefile remove dplayx from the WINE_DLLS line. That worked, Now I'm stopped at wine's shell32.dll. James |
|
From: James T. <jim...@ad...> - 2002-07-09 01:03:00
|
David Kredba wrote: > > From clear cvs co tree I got : > > make -f makefile.ros -C ./../wine/dlls/dplayx > make[1]: Entering directory `d:/ros/wine/dlls/dplayx' > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dpclass > factory.c -o dpclassfactory.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplay.c > -o dplay.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplaysp > .c -o dplaysp.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplayx_ > global.c -o dplayx_global.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplayx_ > main.c -o dplayx_main.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplayx_ > messages.c -o dplayx_messages.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplobby > .c -o dplobby.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c lobbysp > .c -o lobbysp.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c name_se > rver.c -o name_server.o > gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../.. > /../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplayx. > dll.dbg.c -o dplayx.dll.dbg.o > gcc -Wl,--base-file,base.tmp \ > -Wl,--entry,_DllMain@12 \ > -mdll -Wl,--image-base,0x76310000 \ > -o junk.tmp \ > ../../ole/uuid.o dpclassfactory.o dplay.o dplaysp.o > dplayx_global.o > dplayx_main.o dplayx_messages.o dplobby.o lobbysp.o name_server.o dplayx. > dll.dbg.o ../../../reactos/dk/w32/lib/ntdll.a > ../../../reactos/dk/w32/lib/kernel32.a ../../../reactos/dk/w32/lib/user32.a > ../../../reactos/dk/w32/lib/ > ole32.a ../../../reactos/dk/w32/lib/libwine.a -lwinmm > dplobby.o(.text+0x26bf):dplobby.c: undefined reference to > `ConvertToGlobalHandle@4' > dplobby.o(.text+0x26e9):dplobby.c: undefined reference to > `ConvertToGlobalHandle@4' > dplobby.o(.text+0x2713):dplobby.c: undefined reference to > `ConvertToGlobalHandle@4' > make[1]: *** [dplayx.nostrip.dll] Error 1 > make[1]: Leaving directory `d:/ros/wine/dlls/dplayx' > make: *** [dplayx] Error 2 > > David > Hi, I'm stuck at that same place too. James |
|
From: James T. <jim...@ad...> - 2002-07-09 01:01:33
|
James Tabor wrote: > > Hi, > I'm using a linux box to build ROS, it looks like I'm missing something here. > I set export ROS_BUILD_WINE = yes, is there anything else I need to set to clear > this problem? > Thanks, > James > > i386-mingw32-gcc -I../../include -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK > -I../../../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c > y.tab.c -o y.tab.o In file included from wrctypes.h:24, > from wrc.h:25, > from ./parser.y:135: > ../../include/windef.h:152: warning: `MAX_PATH' redefined > /usr/lib/gcc-lib/i386-mingw32/2.95.3-6/../../../../i386-mingw32/include/stdlib.h:62: > warning: this is the location of the previous definition > > i386-mingw32-gcc -Wl,--subsystem,console \ > -Wl,--entry,_mainCRTStartup \ > -o wrc.nostrip.exe \ > dumpres.o genres.o lex.ppl.o lex.yy.o newstruc.o ppy.tab.o preproc.o readres.o utils.o > wrc.o writeres.o y.tab.o ../../../reactos/dk/w32/lib/wine_unicode.a -liberty > -lfl /usr/lib/gcc-lib/i386-mingw32/2.95.3-6/../../../../i386-mingw32/bin/ld: > cannot find -lfl > make[1]: *** [wrc.nostrip.exe] Error 1 > make[1]: Leaving directory `/scsi/ros/wine/tools/wrc' > make: *** [wrc] Error 2 > Okay, I removed fl from ./wine/tools/wrc/makefile.ros and now it works. James |
|
From: James T. <jim...@ad...> - 2002-07-09 00:13:11
|
Hi,
I'm using a linux box to build ROS, it looks like I'm missing something here.
I set export ROS_BUILD_WINE = yes, is there anything else I need to set to clear
this problem?
Thanks,
James
i386-mingw32-gcc -I../../include -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK
-I../../../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c
y.tab.c -o y.tab.o In file included from wrctypes.h:24,
from wrc.h:25,
from ./parser.y:135:
../../include/windef.h:152: warning: `MAX_PATH' redefined
/usr/lib/gcc-lib/i386-mingw32/2.95.3-6/../../../../i386-mingw32/include/stdlib.h:62:
warning: this is the location of the previous definition
i386-mingw32-gcc -Wl,--subsystem,console \
-Wl,--entry,_mainCRTStartup \
-o wrc.nostrip.exe \
dumpres.o genres.o lex.ppl.o lex.yy.o newstruc.o ppy.tab.o preproc.o readres.o utils.o
wrc.o writeres.o y.tab.o ../../../reactos/dk/w32/lib/wine_unicode.a -liberty
-lfl /usr/lib/gcc-lib/i386-mingw32/2.95.3-6/../../../../i386-mingw32/bin/ld:
cannot find -lfl
make[1]: *** [wrc.nostrip.exe] Error 1
make[1]: Leaving directory `/scsi/ros/wine/tools/wrc'
make: *** [wrc] Error 2
|
|
From: David K. <kr...@mb...> - 2002-07-08 22:36:08
|
From clear cvs co tree I got :
make -f makefile.ros -C ./../wine/dlls/dplayx
make[1]: Entering directory `d:/ros/wine/dlls/dplayx'
gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../..
/../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dpclass
factory.c -o dpclassfactory.o
gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../..
/../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplay.c
-o dplay.o
gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../..
/../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplaysp
.c -o dplaysp.o
gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../..
/../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplayx_
global.c -o dplayx_global.o
gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../..
/../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplayx_
main.c -o dplayx_main.o
gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../..
/../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplayx_
messages.c -o dplayx_messages.o
gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../..
/../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplobby
.c -o dplobby.o
gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../..
/../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c lobbysp
.c -o lobbysp.o
gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../..
/../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c name_se
rver.c -o name_server.o
gcc -D__WINE__ -D__REACTOS__ -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -I../..
/../reactos/include/wine -I./ -I../../include -pipe -march=i386 -c dplayx.
dll.dbg.c -o dplayx.dll.dbg.o
gcc -Wl,--base-file,base.tmp \
-Wl,--entry,_DllMain@12 \
-mdll -Wl,--image-base,0x76310000 \
-o junk.tmp \
../../ole/uuid.o dpclassfactory.o dplay.o dplaysp.o
dplayx_global.o
dplayx_main.o dplayx_messages.o dplobby.o lobbysp.o name_server.o dplayx.
dll.dbg.o ../../../reactos/dk/w32/lib/ntdll.a
../../../reactos/dk/w32/lib/kernel32.a ../../../reactos/dk/w32/lib/user32.a
../../../reactos/dk/w32/lib/
ole32.a ../../../reactos/dk/w32/lib/libwine.a -lwinmm
dplobby.o(.text+0x26bf):dplobby.c: undefined reference to
`ConvertToGlobalHandle@4'
dplobby.o(.text+0x26e9):dplobby.c: undefined reference to
`ConvertToGlobalHandle@4'
dplobby.o(.text+0x2713):dplobby.c: undefined reference to
`ConvertToGlobalHandle@4'
make[1]: *** [dplayx.nostrip.dll] Error 1
make[1]: Leaving directory `d:/ros/wine/dlls/dplayx'
make: *** [dplayx] Error 2
David
|
|
From: Steven E. <ste...@ya...> - 2002-07-08 20:57:37
|
fixed all 3 --- David Kredba <kr...@mb...> wrote: > Dtto. > > There are no makefile.ros files in these folders in > the cvs tree. > > David > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Oh, it's good to be a geek. > http://thinkgeek.com/sf > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: David K. <kr...@mb...> - 2002-07-08 17:42:06
|
Dtto. There are no makefile.ros files in these folders in the cvs tree. David |
|
From: Royce3 <ro...@ev...> - 2002-07-08 17:39:41
|
If I had to guess, I'd say nasm.exe is 16-bit dos, and nasmw.exe is 32-bit win32 PE. If that's the case, then copying nasm.exe to nasmw.exe would only cause a reduction in performance. > >Subject: Re: [ros-kernel] today's cvs - build errors > From: Robert Dickenson <od...@pn...> > Date: Mon, 08 Jul 2002 22:57:23 +1000 > To: rea...@li... > > >> >>Ah hah! I found the problem! >>Apparently we switched from using NASM.EXE to NASMW.EXE. I only had the >>nasm.exe in my mingw directory. > >I have simply copied the file in the past when missing either one. Is their a >difference between these two versions anything in ReactOS depends upon? > >Thanks, >Robert. > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Oh, it's good to be a geek. >http://thinkgeek.com/sf >_______________________________________________ >reactos-kernel mailing list >rea...@li... >https://lists.sourceforge.net/lists/listinfo/reactos-kernel |
|
From: David K. <kr...@mb...> - 2002-07-08 17:29:38
|
There is no makefile.ros file in ../wine/programs/expand folder. I use cvs update -d -C for updating my local cvs tree. If I do cvs co wine it is truly not transport makefile.ros for me. David |
|
From: David K. <kr...@mi...> - 2002-07-08 15:23:01
|
The bug is there.
1.
I use cvs update -d -C .
2.
I made full cvs co.
The bug is in cvs tree.
make[1]: Entering directory `D:/ros/wine/dlls/rpcrt4'
dlltool --as=as --dllname rpcrt4.dll \
--def ./rpcrt4.def \
--output-lib ../../../reactos/dk/w32/lib/rpcrt4.a \
--kill-at
make[1]: Leaving directory `D:/ros/wine/dlls/rpcrt4'
make -f makefile.ros -C ./../wine/programs/control implib
make[1]: Entering directory `D:/ros/wine/programs/control'
make[1]: Nothing to be done for `implib'.
make[1]: Leaving directory `D:/ros/wine/programs/control'
make -f makefile.ros -C ./../wine/programs/expand implib
make[1]: makefile.ros: No such file or directory
make[1]: *** No rule to make target `makefile.ros'. Stop.
make[1]: Entering directory `D:/ros/wine/programs/expand'
make[1]: Leaving directory `D:/ros/wine/programs/expand'
make: *** [expand_implib] Error 2
On 08 Jul 2002 09:27 CEST you wrote:
> you will need to make sure cvs is set yo checkout new
> directorys. I've added the expand.exe util from wine
> to wine/programs
>
|
|
From: Steven E. <ste...@ya...> - 2002-07-08 14:43:35
|
os2ss is now in the root with reactos, rosapps, wine and psx. At some point I guess we could rename wine to w32 or something but it really doesnt matter. Your source tree should look like this / /reactos /rosapps /wine /psx /os2ss Steven --- "Robert K." <ro...@ko...> wrote: > What is now about the split of the repository in > more specific ones? > > Where will the os2ss then reside? > __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: Robert K. <ro...@ko...> - 2002-07-08 14:32:35
|
What is now about the split of the repository in more specific ones? Where will the os2ss then reside? Steven Edwards schrieb: >I should be done syncing everything by sunday but as >it stands right now at 5 am est wine/programs and dlls >are totaly hosed. Once I am done syncing everything >that can be built under Mingw wiht MSYS will be able >to be built by our buildsystem. > >If anyone is interested and knows our build system >well I need to minor changes made. Currently I can >work around them but the 2 issues are > >1. *.def - winebuild can automaticly build these from >the specs so we should adapt the system to do this. > >2. wine resources - All wine resources must first pass >thought the wrc before going to windress. > >Thanks >Steven > >__________________________________________________ >Do You Yahoo!? >Sign up for SBC Yahoo! Dial - First Month Free >http://sbc.yahoo.com > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Got root? We do. >http://thinkgeek.com/sf >_______________________________________________ >reactos-kernel mailing list >rea...@li... >https://lists.sourceforge.net/lists/listinfo/reactos-kernel > > |
|
From: Robert K. <ro...@ko...> - 2002-07-08 14:21:09
|
What stays against a winlogon that lives in two worlds? If the GUI is already active, winlogon uses Windowing functions and else it uses the console API to gather USER and PW. Eric Kohl schrieb: >"Steven Edwards" <ste...@ya...> wrote: > > > > >>I would like it if it didnt do a GUI boot by default >>and you just had to type "win" or something but thats >>just me. >> >> > >I suggest a new kernel command line option '/NOGUI'. Just typing "win" to >start the gui won't work because winlogon must always be the first gui app. > >Eric > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >We have stuff for geeks like you. >http://thinkgeek.com/sf >_______________________________________________ >reactos-kernel mailing list >rea...@li... >https://lists.sourceforge.net/lists/listinfo/reactos-kernel > > |
|
From: Royce M. I. <ro...@ev...> - 2002-07-08 13:01:02
|
make was successful, but now make install is failing :) Almost there :) It looks like it's having a problem finding zlib. Here's the pertinent snippet: make -C drivers/lib/zlib install make[1]: *** No rule to make target `zlib.sym', needed by `../../../reactos/system32/zlib.a'. Stop. make[1]: Entering directory `C:/reactos/drivers/lib/zlib' make[1]: Leaving directory `C:/reactos/drivers/lib/zlib' C:\MINGW\BIN\MAKE.EXE: *** [zlib_install] Error 2 I can't troubleshoot this until I get home 'cause I'm already way late for work :) Will try this evening. Royce3 |
|
From: Steven E. <ste...@ya...> - 2002-07-08 12:58:19
|
> >Ah hah! I found the problem! > >Apparently we switched from using NASM.EXE to > NASMW.EXE. I only had the > >nasm.exe in my mingw directory. > > I have simply copied the file in the past when > missing either one. Is their a > difference between these two versions anything in > ReactOS depends upon? Thats what I have always done and never had a problem. Steven __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: Robert D. <od...@pn...> - 2002-07-08 12:56:35
|
> >Ah hah! I found the problem! >Apparently we switched from using NASM.EXE to NASMW.EXE. I only had the >nasm.exe in my mingw directory. I have simply copied the file in the past when missing either one. Is their a difference between these two versions anything in ReactOS depends upon? Thanks, Robert. |
|
From: Royce M. I. <ro...@ev...> - 2002-07-08 12:43:47
|
Went and checked the results this morning. It still failed after doing a make clean and then make again. Ah hah! I found the problem! Apparently we switched from using NASM.EXE to NASMW.EXE. I only had the nasm.exe in my mingw directory. Royce3 |
|
From: Steven E. <ste...@ya...> - 2002-07-08 12:37:13
|
your right I dont see why it trys to clean tools when it does. go ahead and patch it. > Having make clean the tools directory (and > particularly the .exe's) as > the very last step of 'make clean' should fix it > properly. > > Robert. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: Robert D. <od...@pn...> - 2002-07-08 12:33:44
|
> >make clean failed, but I was able to fix it by copying RDEL.EXE to the >C:\ReactOS directory. This is the quick fix I have used a couple of times since a while back. make clean actually uses rdel to delete rdel from the tools directory. This in itself works fine but make then tries to delete some more files. Having make clean the tools directory (and particularly the .exe's) as the very last step of 'make clean' should fix it properly. Robert. |
8 messages has been excluded from this view by a project administrator.
