On Beta Testing
Moderator: Forum Moderators
- Pentarctagon
- Project Manager
- Posts: 5564
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: On Beta Testing
I'm using the same versions of zlib/bzip2 as aquileia and the same version of boost as you are.
My PC, and all the PCs I have access to, are 64-bit windows 7. So if it is a 32/64 problem, I have no way of testing it. On the bzip2 Downloads page it does say " It should run on practically any 32 or 64 bit computer" though, so it seems unlikely.
My PC, and all the PCs I have access to, are 64-bit windows 7. So if it is a 32/64 problem, I have no way of testing it. On the bzip2 Downloads page it does say " It should run on practically any 32 or 64 bit computer" though, so it seems unlikely.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
- loonycyborg
- Windows Packager
- Posts: 295
- Joined: April 1st, 2008, 4:45 pm
- Location: Russia/Moscow
Re: On Beta Testing
It links against both boost_iostreams-mgw45-mt-1_46_1 and bz2 in correct order yet some symbols from boost_iostreams that reference libbz2 can't be resolved. Maybe bz2 compiled with msvc is incompatible with mingw programs. But I think all C libs are supposed to be compatible.. is libbz2 in scons-dependencies\lib for you? does it come from my wesnoth-deps or it's what you downloaded? You can try to substitute one for the other.
"meh." - zookeeper
Re: On Beta Testing
http://www.mingw.org/wiki/MSVC_and_MinGW_DLLsloonycyborg wrote:Maybe bz2 compiled with msvc is incompatible with mingw programs. But I think all C libs are supposed to be compatible..
- Pentarctagon
- Project Manager
- Posts: 5564
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: On Beta Testing
I'm using the bzip2 source code from the official site. I tried substituting yours in, but bzip2 support was still not detected.
I am also not using msvc, I'm using MinGW, so lib compatibility shouldn't' be an issue.
I am also not using msvc, I'm using MinGW, so lib compatibility shouldn't' be an issue.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: On Beta Testing
Ok well, if it still didn't work it means I might not have given the best advice
What exactly is making it easier for Code::Blocks? Does code::blocks gather the required libraries for you? Is it just that Visual Studio is easier to work with on Windows?
Should we add support for the visual studio compiler to the SCons script? As I understand that is quite possible, I just don't know how to do it atm.
What exactly is making it easier for Code::Blocks? Does code::blocks gather the required libraries for you? Is it just that Visual Studio is easier to work with on Windows?
Should we add support for the visual studio compiler to the SCons script? As I understand that is quite possible, I just don't know how to do it atm.
- Pentarctagon
- Project Manager
- Posts: 5564
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: On Beta Testing
What makes it easier is that it actually works
More seriously, what makes code::blocks easier is that it came with step-by-step instructions for how to set it up and use it. Literally, ~95% of my thought process behind how to try compiling wesnoth for the first time was:
"Oh hey look, instructions."
Also, in other news, I was able to get past the bzip2 support by setting the boostlibdir to the pre-compiled libraries from the code::blocks instructions. Now it fails with on the Pango check with:
edit - Fixed that, now it's failing with:
edit2 - This is my current setup. Just extract the archive to where ever the wesnoth source code is installed.
make.bat in "scons_dependencies/boost_1_46_1" builds boost (in theory) with zlib/bzip2 support. Since that doesn't seem to work at the moment, it instead looks at the scons_dependencies/lib_boost folder, which has the libraries from the lib_tdm_gcc folder from the code::blocks pre-compiled libraries download.
scons.bat in the wesnoth root directory generates the .scons-option-cache, runs pango-querymodules, gdk-pixbuf-query-loaders, gtk-query-immodules-3.0, and finally scons with --config=force.
edit2.1 - The above scripts assume that you have MinGW installed and in your PATH variable, and that scons is in the "C:\Python27\Scripts" directory.
More seriously, what makes code::blocks easier is that it came with step-by-step instructions for how to set it up and use it. Literally, ~95% of my thought process behind how to try compiling wesnoth for the first time was:
"Oh hey look, instructions."
Also, in other news, I was able to get past the bzip2 support by setting the boostlibdir to the pre-compiled libraries from the code::blocks instructions. Now it fails with on the Pango check with:
Code: Select all
pkg-config is not recognized as an internal or external command, operable program or batch file.
Code: Select all
Package \ was not found in the pkg-config search path. Perhaps you should add the directory containing '\.pc' to the PKG_CONFIG_PATH environment variable. No package '\' found.
make.bat in "scons_dependencies/boost_1_46_1" builds boost (in theory) with zlib/bzip2 support. Since that doesn't seem to work at the moment, it instead looks at the scons_dependencies/lib_boost folder, which has the libraries from the lib_tdm_gcc folder from the code::blocks pre-compiled libraries download.
scons.bat in the wesnoth root directory generates the .scons-option-cache, runs pango-querymodules, gdk-pixbuf-query-loaders, gtk-query-immodules-3.0, and finally scons with --config=force.
edit2.1 - The above scripts assume that you have MinGW installed and in your PATH variable, and that scons is in the "C:\Python27\Scripts" directory.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: On Beta Testing
Perhaps the term "C libs" is ambiguious. From my understanding, not all libs associated with C are compatible. unix and linux C libs seem rather incompatable.loonycyborg wrote:But I think all C libs are supposed to be compatible..
If I spoke the truth, they would put me in a straitjacket. So, I left the society.
- Pentarctagon
- Project Manager
- Posts: 5564
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: On Beta Testing
We're talking about libraries that were both compiled on Windows, just with different compilers though.sylph wrote:Perhaps the term "C libs" is ambiguious. From my understanding, not all libs associated with C are compatible. unix and linux C libs seem rather incompatable.loonycyborg wrote:But I think all C libs are supposed to be compatible..
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: On Beta Testing
Well, C doesn't have C++ name mangling, but you can have various types of calling convention. 32-bit vs 64-bit can also be an issue.
See http://en.wikipedia.org/wiki/Applicatio ... _interface
See http://en.wikipedia.org/wiki/Applicatio ... _interface
- Pentarctagon
- Project Manager
- Posts: 5564
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: On Beta Testing
So... basically I'd need to compile every dependency from source?
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: On Beta Testing
Hmm so according to the code::blocks project file readme, 64 bit windows is not currently supported on that tool-chain.
https://github.com/wesnoth/wesnoth/blob ... ME.txt#L22
Yet you report that that was working for you?
https://github.com/wesnoth/wesnoth/blob ... ME.txt#L22
Yet you report that that was working for you?
- Pentarctagon
- Project Manager
- Posts: 5564
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: On Beta Testing
Windows is 64-bit, but I'm using the 32-bit version of the compiler.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
- loonycyborg
- Windows Packager
- Posts: 295
- Joined: April 1st, 2008, 4:45 pm
- Location: Russia/Moscow
Re: On Beta Testing
To get around the pkg-config issue comment two lines in scons/pango.py
I still need to figure out how to escape that '>' in cross-platform way..
Code: Select all
if require_version:
version_arg = " \\>= " + require_version
"meh." - zookeeper
- loonycyborg
- Windows Packager
- Posts: 295
- Joined: April 1st, 2008, 4:45 pm
- Location: Russia/Moscow
Re: On Beta Testing
I found a way to solve this issue in a way that is worthy of getting committed. It's in master branch atm.
"meh." - zookeeper
- Pentarctagon
- Project Manager
- Posts: 5564
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: On Beta Testing
Awesome, thanks
So, the good news: It compiles and runs now!
The bad news, in order of increasing severity:
1) I get this warning when using the -j option:
but it doesn't seem to affect the build.
2) I get ~10 billion of these errors from boost:
3) When trying to run it, I got this error:
Getting a second copy of intl.dll from the code::blocks dlls and renaming it to libintl-8.dll seems to fix this, however then when recompiling it gives the error:
which is odd, since that error doesn't occur when libintl-8.dll doesn't exist at all.
4) The final 4 checks fail with this:
edit - Is the bbcode not working for anyone else?
edit2 - For the record, as far as speed goes:
Code::blocks took 3:20
scons* took 2:08
*without a "hot ccache". It wasn't compiling at all until ~30 minutes ago, so I haven't bothered looking up what it is yet.
So it seems that scons does have fairly significant a speed advantage over code::blocks.
So, the good news: It compiles and runs now!
The bad news, in order of increasing severity:
1) I get this warning when using the -j option:
Code: Select all
warning: you do not seem to have the pywin32 extensions installed;
parallel (-j) builds may not work reliably with open python files.
2) I get ~10 billion of these errors from boost:
Code: Select all
warning: dereferencing type-punned pointer will break strict-aliasing rules
Code: Select all
The procedure entry point libintl_setlocale could not be located in the dynamic link library libintl-8.dll
Code: Select all
The procedure entry point __printf__ could not be located in the dynamic link library libintl-8.dll
4) The final 4 checks fail with this:
Code: Select all
Checking for dbus-1... (cached) no
Checking for fribidi >= 0.10.9... (cached) no
Can't find libfribidi, disabling freebidi support.
Checking for Boost unit_test_framework library... no
WARN: Unit tests are disabled because their prerequisites are not met
If any config checks fail, look in build/config.log for details
If a check fails spuriously due to caching, use --config=force to force its rerun
NLS tools are not present...
NLS catalogue installation is disabled.
utils is not recognized as an internal or external command.
edit2 - For the record, as far as speed goes:
Code::blocks took 3:20
scons* took 2:08
*without a "hot ccache". It wasn't compiling at all until ~30 minutes ago, so I haven't bothered looking up what it is yet.
So it seems that scons does have fairly significant a speed advantage over code::blocks.
Last edited by Pentarctagon on July 1st, 2014, 12:48 am, edited 6 times in total.
Reason: Enable BBCode
Reason: Enable BBCode
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code