Can you please post the list of errors to wine-devel, so people are aware of the problems (and hopefully send patches to fix them :))?
Complete compile error log is attached.
Now that we have this build, can we get rid of: Wine programs for Windows from the "Support Files" package?
Done.
Ivan.
On Wednesday 17 March 2004 18:05, Ivan Leo Murray-Smith wrote:
Can you please post the list of errors to wine-devel, so people are aware of the problems (and hopefully send patches to fix them :))?
Complete compile error log is attached.
../../../wine-src/tools/winebuild/spec32.c: In function `BuildSpec32File': ../../../wine-src/tools/winebuild/spec32.c:492: warning: implicit declaration of function `getpagesize' ../../../wine-src/tools/winegcc/utils.c: In function `spawn': ../../../wine-src/tools/winegcc/utils.c:313: warning: passing arg 3 of `spawnvp' from incompatible pointer type
To be expected. I don't think we will ever want to build winebuild/winegcc on MinGW.
comctl32.exp(.edata+0x6ac):fake: undefined reference to `f1' comctl32.exp(.edata+0x6b0):fake: undefined reference to `f2' comctl32.exp(.edata+0x6b4):fake: undefined reference to `f3'
shlwapi.exp(.edata+0x5fc):fake: undefined reference to `f1' shlwapi.exp(.edata+0x600):fake: undefined reference to `f2'
Bug in binutils. A fix by Dimitry is in latest binutils. My latest MinGW RPM packages include the fix:
Don't know if the latest Debian packages include the fix.
capture.o(.text+0xef6): In function `dscenum_callback': /usr/src/wine-pe/dlls/dsound/tests/../../../../wine-src/dlls/dsound/tests/capture.c:268: undefined reference to `DirectSoundCaptureCreate@12'
MinGW DirectX headers are way behind. My RPM packages include a patch that adds the necessary headers and guids.
../../../wine-src/dlls/gdi/printdrv.c: In function `CreateSpoolFile': ../../../wine-src/dlls/gdi/printdrv.c:487: warning: implicit declaration of function `pipe' ../../../wine-src/dlls/gdi/printdrv.c:491: warning: implicit declaration of function `fork'
x11drv, gdi, kernel, ntdll and user will probably never build on MinGW. Use native versions for the last 4 of these.
../../../wine-src/dlls/icmp/ip.h:50: parse error before "u_int"
Some networking related dlls rely heavily on Unix networking APIs. It will probably take a while before they are rewritten to build on MinGW (with help from ReactOS perhaps?).
In file included from ../../../wine-src/dlls/msvcrt/cpp.c:35: ../../../wine-src/include/msvcrt/stdlib.h:161: conflicting types for `_swab' /usr/local/cross-tools/i586-mingw32msvc/include/string.h:93: previous declaration of `_swab'
msvcrt is almost fixed since my latest patch.
../../../wine-src/dlls/rpcrt4/rpcrt4_main.c: In function `UuidCreate': ../../../wine-src/dlls/rpcrt4/rpcrt4_main.c:435: warning: implicit declaration of function `gettimeofday'
gettimeofday() is the only Unix API used by rpcrt4. I'm planning on fixing this one as well.
I think it would be nice if we provided just two packages: one with PE versions of our programs. Just the relevant ones that actually build, so no winecfg or winedbg for example, and a second package with PE dlls that build.
-Hans
On March 19, 2004 7:54 am, Hans Leidekker wrote:
I think it would be nice if we provided just two packages: one with PE versions of our programs. Just the relevant ones that actually build, so no winecfg or winedbg for example, and a second package with PE dlls that build.
That's a good idea. In fact, maybe 3 packages: programs, dlls, headers: wine-prgs-<version>[-mingw].zip wine-dlls-<version>[-mingw].zip wine-hdrs-<version>.zip
MinGW folks split up the headers as well, (in their w32api package), and I think they are useful in and of themselves. Ivan?
On Friday 19 March 2004 14:21, Dimitrie O. Paun wrote:
That's a good idea. In fact, maybe 3 packages: programs, dlls, headers: wine-prgs-<version>[-mingw].zip wine-dlls-<version>[-mingw].zip wine-hdrs-<version>.zip
MinGW folks split up the headers as well, (in their w32api package), and I think they are useful in and of themselves. Ivan?
We could add the import libs to that package as well and call it wine-w32api ;-)
-Hans
On Fri, 19 Mar 2004, Hans Leidekker wrote:
That's a good idea. In fact, maybe 3 packages: programs, dlls, headers: wine-prgs-<version>[-mingw].zip wine-dlls-<version>[-mingw].zip wine-hdrs-<version>.zip
MinGW folks split up the headers as well, (in their w32api package), and I think they are useful in and of themselves. Ivan?
We could add the import libs to that package as well and call it wine-w32api ;-)
Why not, it sounds like a great idea. It's better to try to match what's already out there. And besides, it's more logical anyway.
--- Hans Leidekker hans@it.vu.nl wrote:
Some networking related dlls rely heavily on Unix networking APIs. It
will probably take a while before they are rewritten to build on MinGW (with help from ReactOS perhaps?).
I tried to fix wininet but the WINE winsock headers are kind of a mess. I will try to make more time to look at it.
../../../wine-src/dlls/rpcrt4/rpcrt4_main.c: In function `UuidCreate': ../../../wine-src/dlls/rpcrt4/rpcrt4_main.c:435: warning: implicit declaration of function `gettimeofday'
gettimeofday() is the only Unix API used by rpcrt4. I'm planning on fixing this one as well.
Cool, thanks.
I think it would be nice if we provided just two packages: one with PE versions of our programs. Just the relevant ones that actually build, so no winecfg or winedbg for example, and a second package with PE dlls that build.
Thanks Steven
__________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com
-
Dimitrie O. Paun -
Dimitrie O. Paun -
Hans Leidekker -
Ivan Leo Murray-Smith -
Steven Edwards