UFO:Alien Invasion
Development => Coding => Topic started by: Destructavator on August 23, 2009, 03:48:42 pm
-
http://destructavator.com/92dl/Codeblocks.zip
(Approx. ~80MB in size)
This includes the OpenAL library, which is needed to compile radiant.
-
http://destructavator.com/92dl/Codeblocks.zip
(Approx. ~80MB in size)
This includes the OpenAL library, which is needed to compile radiant.
Hi Destructavator,
Just want to let u know that it works for me now. :D AFAIK, i added nothing to the directory....
I ma porting it home and making a fresh install onto my home lappy, with reference to an external harddisk to make it portable. HeHe. Let u know if it can be done, and if anything else is lacking. Hehe.
-
I tried the zip, and it works better.
But I'm getting linker errors when building radiant, starting with
...undefined reference to _imp__alcOpenDevice...
Guess I have to add some dir to the library search.
Which one ?
-
which target did you build? windows or windows_debug? the openal linker flags were missing in windows - they were only set in windows_debug - but that is fixed now (r26058)
-
Yes, I built the windows exe.
Yes, that error is gone as of R26079. We're getting close ;)
Now I get (on both windows and debug):
WARNING: Can't read file's timestamp: C:\UFO\src\tools\radiant\selection\BestPoint.cpp
WARNING: Can't read file's timestamp: C:\UFO\src\tools\radiant\selection\Intersection.cpp
WARNING: Can't read file's timestamp: C:\UFO\src\tools\radiant\selection\Manipulatables.cpp
WARNING: Can't read file's timestamp: C:\UFO\src\tools\radiant\selection\Manipulators.cpp
Linking executable: ..\..\radiant\uforadiant.exe
mingw32-g++.exe: .objs\radiant\src\tools\radiant\selection\BestPoint.o: No such file or directory
mingw32-g++.exe: .objs\radiant\src\tools\radiant\selection\Intersection.o: No such file or directory
mingw32-g++.exe: .objs\radiant\src\tools\radiant\selection\Manipulatables.o: No such file or directory
mingw32-g++.exe: .objs\radiant\src\tools\radiant\selection\Manipulators.o: No such file or directory
-
please retry with latest trunk revision
-
It's working now, thanks :)
Shouldn't we put up Destructavator's zip now as the official codeblocks.zip in the wiki ?
-
is there a difference to my version?
-
I took the zip from the wiki some four days ago and still got those "missing alc.h" errors.
So unless you changed it meanwhile, yes, there is a difference.
May I also repeat my suggestion to give that zip some sort of versioning ?
If it is too inconvenient for you to change the filename every time, what about a file named Version_1.x.txt in the CB root ?
-
that would be doable - btw. i was refering to mattn.ninex.info c::b package
-
that would be doable - btw. i was refering to mattn.ninex.info c::b package
I think that is the current version in the wiki - I just checked the wiki and the hyperlink there for codeblocks is:
http://mattn.ninex.info/download/codeblocks.zip
...Or did I misunderstand?
If you want to grab the version I built, you're more than welcome to use that or change the link in the wiki to it - but please let me know if you plan to link directly to it where it is so I don't accidentally delete it when I clean out my website from time to time.
-
you will need a new c::b package version to compile uforadiant - there is a new dependency. the codeblocks.sh script is already updated. but a new package it not yet available.
-
I just updated my SVN working copy - the new script works, everything downloaded and created the new package OK.
I'll test the new package (compiling the game and UFORadiant), and if it works I'll upload it (the new CodeBlocks package) shortly.
If all goes well I should have a link to the new CB package in ~1 hour or so.
-
Hmmm... It seems with rev 26217 the game compiles but not uforadiant.
Build messages:
||=== ufo, windows_debug ===|
E:\UFOai\src\client\renderer\r_error.h|48|warning: 'R_CheckErrorDebug' defined but not used|
||=== uforadiant, windows_debug ===|
||warning: command line option "-Wno-non-virtual-dtor" is valid for C++/ObjC++ but not for C|
||warning: command line option "-Wno-non-virtual-dtor" is valid for C++/ObjC++ but not for C|
||warning: command line option "-Wno-non-virtual-dtor" is valid for C++/ObjC++ but not for C|
||warning: command line option "-Wno-non-virtual-dtor" is valid for C++/ObjC++ but not for C|
||warning: command line option "-Wno-non-virtual-dtor" is valid for C++/ObjC++ but not for C|
||warning: command line option "-Wno-non-virtual-dtor" is valid for C++/ObjC++ but not for C|
||warning: command line option "-Wno-non-virtual-dtor" is valid for C++/ObjC++ but not for C|
||warning: command line option "-Wno-non-virtual-dtor" is valid for C++/ObjC++ but not for C|
||warning: command line option "-Wno-non-virtual-dtor" is valid for C++/ObjC++ but not for C|
E:\UFOai\src\tools\radiant\radiant\exec.cpp||In function 'void exec_spawn_process(ExecCmd*, void (*)(void*))':|
E:\UFOai\src\tools\radiant\radiant\exec.cpp|196|warning: statement has no effect|
E:\UFOai\src\tools\radiant\radiant\exec.cpp||In function 'void exec_run(Exec*)':|
E:\UFOai\src\tools\radiant\radiant\exec.cpp|396|warning: statement has no effect|
..\..\src\tools\radiant\libs\..\..\..\game\..\shared\shared.h|94|warning: 'libintl_printf' is an unrecognized format function type|
..\..\src\tools\radiant\libs\..\..\..\game\..\shared\shared.h|98|warning: 'libintl_printf' is an unrecognized format function type|
..\..\src\tools\radiant\libs\..\..\..\game\q_shared.h|159|warning: 'libintl_printf' is an unrecognized format function type|
..\..\src\tools\radiant\libs\..\..\..\game\q_shared.h|160|warning: 'libintl_printf' is an unrecognized format function type|
..\..\src\tools\radiant\libs\..\..\..\game\q_shared.h|161|warning: 'libintl_printf' is an unrecognized format function type|
E:\UFOai\src\tools\radiant\radiant\server.cpp|204|warning: 'dllexport' attribute ignored|
ld.exe||cannot find -lgtksourceview-1.0|
||=== Build finished: 1 errors, 18 warnings ===|
The build log is attached in a text file, as well.
Is the new package broken? Or is it a physical hardware problem with the computer's operator (my fault)?
-
Update: Hang on, I saw an update regarding this (in SVN logs) after updating from SVN again, hopefully the update fixed it.
I'll try again and report back shortly.
Edit/Update: Nope, it is still broken, same error... :(
-
update was commited with r26221 - please retry
-
Updated to r26222, and I got a new error in the MinGW32 script (I copied the last few lines and pasted them below with the error).
I'll try to "clean" and retry, and if I can manage to change something that makes it work again, I'll report back shortly.
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
downloading CB_20090817_rev5731_win32.7z...
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
downloading glib_2.20.3-1_win32.zip...
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
downloading glib-dev_2.20.3-1_win32.zip...
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
downloading gtk+-dev_2.16.2-1_win32.zip...
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
downloading gtksourceview-dev-2.0.2.zip...
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
downloading pango-dev_1.24.2-1_win32.zip...
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
downloading atk-dev_1.26.0-1_win32.zip...
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
downloading gettext-tools-0.17.zip...
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
downloading gettext-runtime-dev-0.17-1.zip...
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
downloading cairo-dev_1.8.6-1_win32.zip...
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
downloading pkg-config-0.23-2.zip...
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
downloading gettext-runtime-0.17-1.zip...
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
downloading libxml2-dev-2.6.27.zip...
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
downloading gtkglext-1.2.zip...
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
downloading openal.zip...
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
downloading svn-win32-1.6.1.zip...
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
downloading directx-devel.tar.gz...
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = E:\codeblocks\MinGW/etc/wgetrc
Start to extract and prepare the downloaded archives into /tmp/tmp_codeblocks/codeblocks/MinGW
Error: Could not remove tools files
Dave@D-1F333CC28 /e/ufoai/contrib/scripts
$
-
Ah-Ha! It seems that with the past r26217, the broken script left behind bits and pieces of files/data that didn't come out with the "clean" option running the new script.
I was able to find the temporary files where the script was working in Windows Explorer (buried deep in the temporary files app directory in XP) and clean out the broken stuff manually, and now the r26222 script works.
I now have a new Codeblocks package - if It compiles everything OK I'll upload and link to it...
-
It didn't compile everything, but I got different errors.
Logs from CB attached.
-
Just wanted to let you know that I am among those who desperately wait for the new c:B zip...
-
Just wanted to let you know that I am among those who desperately wait for the new c:B zip...
You're not alone. ;)
BTW - I was looking through some topics on the CodeBlocks forum, to see if I was doing everything right, and I stumbled across information on how to make CB portable, so that in Windows the same logged-in user can manage multiple versions of CB in different folders with independent configurations. I tried it out and it works without any headache - I might in fact make the next upload portable when things get fixed.
It's very simple really, just copying one config file so the program looks in the same folder as "codeblocks.exe" instead of the user's appdata path, and deleting the copied file makes it run normally if the user doesn't want it to be portable.
-
That sounds interesting when testing different C:B versions/configurations.
I would prefer just one version that works for all UFO files and doesn't change very often ;)
-
it is fixed now
-
http://www.destructavator.com/92dl/codeblocks_26229.zip
;D
Please note:
- The number is the revision the package is capable of compiling, not the revision of the actual CB program.
- This version can be used as a portable package, If you don't have any settings already in your APPDATA path on Windows it will use the .conf file in the codeblocks directory (wherever you un-zipped it). If you do already have any CB settings from any version of CB (if you've used the IDE on your system before already) it will use those settings in APPDATA and ignore settings in the "codeblocks" directory, because the program looks in APPDATA first before looking in the folder you un-zipped it to.
- If you do use it in a portable manner, and therefore use the provided .conf file with the configuration, you will of course still have to set up some paths and settings tailored for your system, otherwise CodeBlocks will think it is still on my computer and not yours (and obviously not function properly).
- If you don't want to use it as a portable package, just delete the .conf file and it will happily generate settings files in your APPDATA folder for your Windows user account, just as it normally would.
-
Thanks, Destructavator, it *almost* works for me:
Linking executable: ..\..\radiant\uforadiant.exe
.objs\radiant\src\tools\radiant\radiant\material.o:C:/UFO/src/tools/radiant/radiant/material.cpp:59: undefined reference to `ui::MaterialDefinitionView::MaterialDefinitionView()'
.objs\radiant\src\tools\radiant\radiant\material.o:C:/UFO/src/tools/radiant/radiant/material.cpp:60: undefined reference to `ui::MaterialDefinitionView::setMaterial(std::string const&)'
.objs\radiant\src\tools\radiant\radiant\material.o:C:/UFO/src/tools/radiant/radiant/material.cpp:61: undefined reference to `ui::MaterialDefinitionView::append(std::string const&)'
.objs\radiant\src\tools\radiant\radiant\material.o:C:/UFO/src/tools/radiant/radiant/material.cpp:71: undefined reference to `ui::MaterialDefinitionView::getWidget()'
.objs\radiant\src\tools\radiant\radiant\material.o:C:/UFO/src/tools/radiant/radiant/material.cpp:84: undefined reference to `ui::MaterialDefinitionView::save()'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 42 seconds)
5 errors, 17 warnings
-
Ooops, my bad.
svn updated from 26223 to 26236 and it compiles an links happily :)
*bows*
-
... but doesn't run :(
Where is "libgtksourceview-2.0-0.dll" ??
-
... but doesn't run :(
Where is "libgtksourceview-2.0-0.dll" ??
I got the same error with uforadiant, although the game runs fine.
I looked all through the contrib/dll folder and inside the self-extracting archive, I couldn't find this DLL anywhere in the current SVN trunk. I admit I didn't look on the net though, but if uforadiant is going to continue to need it, I'd guess someone should add it to the SVN.
-
Looks like sometime earlier today Mattn just put the missing DLL in the SVN trunk.
For anyone who isn't using SVN but instead using the last beta installer I uploaded for Windows, you can grab the DLL here:
http://ufoai.svn.sourceforge.net/viewvc/ufoai/ufoai/trunk/contrib/dlls/libgtksourceview-2.0-0.dll?view=log
-
And finally radiant works for me again :)
Thx everybody !
-
I'm currently uploading a new CodeBlocks package, seeing that Mattn updated the script for a new version recently, as well as a new debugger version some time back.
Will post a link when its done uploading.
-
http://www.destructavator.com/92dl/codeblocks5859_r26597.zip
The first number is the CodeBlocks revision build (from the CB team, not UFO AI), the second number is the UFO AI revision where the script was updated and is the UFO AI build the package is intended to compile.
I actually didn't have time to test this one (been quite busy today), so I don't know for sure that it will work - Don't throw away your existing, working version until you give this one a full test on the trunk!
-
Looks like this version has a prob with debugging. If I try to start the debugger, it tells me to go to settings, toolchain and set the debug exe. But if I do, gdb.exe IS already set there.
Probably a C::B bug.
Does it behave the same for you ?
-
Sorry I was out for a few days - is this still an issue? I'm currently updating my working copies of everything and recompiling all of it.
I recall a bit back in the SVN logs a new version of the debugger was put into the CB script. I don't know if the new debugger is bugged (LOL, quite a concept!), if its a problem with the new CB version, or if its simply an incompatibility between the two.
-
Not really an issue. I reverted to your 26229.zip and everything works fine.
But it would be interesting if you get the same error (described above) with your installation when you try to start the debugger.