|
Pages: [1]
|
 |
|
Author
|
Topic: Strange events with compilation under windows (Read 2518 times)
|
PePsY
Zebranky food
 Offline
Posts: 5
I'm OnLy Of ViSiT On ThiS PLaNeT
|
Hi there
I spent many days to find a way to successfully compile UQM3 under windows, following instructions in install text files. It wasn't working both on visual C++ and MinGW with differents issues for each one. For MinGW, here the results:
--> build.sh uqm config
Sed stream editor found.
tr found.
Make found.
GNU C compiler found.
windres found.
gcc.exe: no input files
Little-endian machine.
build/unix/build.config: sdl-config: command not found
build/unix/build.config: sdl-config: command not found
gcc.exe: no input files
Simple DirectMedia Layer not found.
------------
Results for visual C++:
(after a huge amount of warnings)
Linking...
zip.obj : error LNK2001: unresolved external symbol _inflate
zip.obj : error LNK2001: unresolved external symbol _inflateInit2_
zip.obj : error LNK2001: unresolved external symbol _inflateEnd
zip.obj : error LNK2001: unresolved external symbol _inflateReset
../../uqmdebug.exe : fatal error LNK1120: 4 unresolved externals
Error executing link.exe.
uqmdebug.exe - 5 error(s), 655 warning(s)
------------
Before to see these results, there was a lack of several libs no mentionned in the install files (install files talk about headers files and DLL files, and apparently visual C++ need some .lib files too included in the packages of zlib, oggvorbis etc). Anyway after adding required files, there is the result, some problems with zip stuff. Finally, I've found a way to bypass this. I've modified 2 files:
zip.c in src\sc2code\libs\uio\zip by emptying the file entirely.
defaultfs.c in src\sc2code\libs\uio (because of the empty zip.c) changing this:
------------
extern uio_FileSystemHandler stdio_fileSystemHandler;
#ifdef HAVE_ZIP
extern uio_FileSystemHandler zip_fileSystemHandler;
#endif
const uio_DefaultFileSystemSetup defaultFileSystems[] = {
{ uio_FSTYPE_STDIO, "stdio", &stdio_fileSystemHandler },
#ifdef HAVE_ZIP
{ uio_FSTYPE_ZIP, "zip", &zip_fileSystemHandler },
#endif
};
------------
into this:
------------
extern uio_FileSystemHandler stdio_fileSystemHandler;
extern uio_FileSystemHandler zip_fileSystemHandler;
const uio_DefaultFileSystemSetup defaultFileSystems[] = {
{ uio_FSTYPE_STDIO, "stdio", &stdio_fileSystemHandler },
};
------------
It's probally not too good for some reasons, but compilation worked fine this time! No errors. However, the EXE takes +425Ko than the original EXE (we don't care, but it's usual?) and it needs MSVCRTD.DLL to run (I guess it's a visual C++ library?). When I use the EXE, all is working fine, but there is a lag in the graphics (not too much but not negligible), especially in battles. It's not lagging with the original EXE. I was wondering...it cannot be associated with my modifs in the 2 files of the zip stuff? I suppose no...there is no link with lag in graphics and the zip stuff. I'm playing with files unzipped anyway. Could it be usual for compilations with visual C++ to lag like this? If I could compile with MinGW, the results shall be differents? What do you think?
|
|
|
|
|
Logged
|
|
|
|
|
|
chmmravatar
*Many bubbles*
Offline
Posts: 109
WHAT IS DONE IS DONE
|
It's probally not too good for some reasons, but compilation worked fine this time! No errors. However, the EXE takes +425Ko than the original EXE (we don't care, but it's usual?) and it needs MSVCRTD.DLL to run (I guess it's a visual C++ library?). When I use the EXE, all is working fine, but there is a lag in the graphics (not too much but not negligible), especially in battles. It's not lagging with the original EXE. I was wondering...it cannot be associated with my modifs in the 2 files of the zip stuff? I suppose no...there is no link with lag in graphics and the zip stuff. I'm playing with files unzipped anyway. Could it be usual for compilations with visual C++ to lag like this? If I could compile with MinGW, the results shall be differents? What do you think?
The increased EXE size, requirement of MSVCRTD.DLL, and slower performance is because you compiled it for "debug," and not for "release."
Anyways, the problem you may be having is that uqm is looking for zlib.lib. The zlib I downloaded didn't have a zlib.lib, but rather libz.lib. So the way you can fix this is by going into the project linking settings and change the "zlib.lib" entry to "libz.lib."
|
|
|
|
|
Logged
|
|
|
|
|
|
|
|
PePsY
Zebranky food
Offline
Posts: 5
I'm OnLy Of ViSiT On ThiS PLaNeT
|
Thanks a lot for all your help, now all my problems are gone! And things work perfectly! You've been very helpfull! 
|
|
|
|
|
Logged
|
|
|
|
chmmravatar
*Many bubbles*
Offline
Posts: 109
WHAT IS DONE IS DONE
|
No prob!
|
|
|
|
|
Logged
|
|
|
|
|
Pages: [1]
|
|
|
|
|
