Build on FreeBSD

[rb1598]

Your instruction set provides a list of dependencies for most linuxes and MacOSX, so the game should be able to build on BSD as well. I am trying to do this, but I have 2 problems:

1. As far as I can tell, the dependencies list for BSD are: boost, libnet, libvorbis, libxml2, openal, libjpeg-turbo, fpc-libpng, wxgtk2-common

(gcc - cmake - curl are installed by default in the base system). Are these the correct dependencies? You can look through the ports collection at http://www.freshports.org/

2. # ./update-workspaces.sh gives error, all from the Makefile for FCollada. When I switch to 0ad/libraries/fcollada/src and run # make, I get same error:

Updating bundled third-party dependencies...

"Makefile", line 3: Missing dependency operator
"Makefile", line 5: Need an operator
"Makefile", line 8: Need an operator
"Makefile", line 275: Missing dependency operator
make: fatal errors encountered -- cannot continue
ERROR: FCollada build failed

Line 3-5-8 in Makefile for FCollada is the if-else-endif statement.

Edited December 8, 2011 by rb1598

[fcxSanya]

Hello.

2. # ./update-workspaces.sh gives error, all from the Makefile for FCollada. When I switch to 0ad/libraries/fcollada/src and run # make, I get same error:

Updating bundled third-party dependencies...
"Makefile", line 3: Missing dependency operator
"Makefile", line 5: Need an operator
"Makefile", line 8: Need an operator
"Makefile", line 275: Missing dependency operator
make: fatal errors encountered -- cannot continue
ERROR: FCollada build failed

From quick googling it looks like you can try to use gmake instead of make to build FCollada.

[rb1598]

Thanks for the reply. A little better, but still problems.

0ad/libraries/fcollada/src># gmake

g++ -fvisibility=hidden -W -Wall -Wno-unused-parameter -Wno-unused-function -DLINUX -fpic  -fno-strict-aliasing -O0 -g -D_DEBUG -DRETAIL -IFCollada `pkg-config libxml-2.0 --cflags` -MD -MF output/debug/FCollada/FCollada.d -c FCollada/FCollada.cpp -o output/debug/FCollada/FCollada.o
In file included from FCollada/FUtils/Platforms.h:84,
             	from FCollada/FUtils/FUtils.h:72,
             	from FCollada/FCollada.h:49,
             	from FCollada/StdAfx.h:13,
             	from FCollada/FCollada.cpp:9:
/usr/include/malloc.h:3:2: error: #error "<malloc.h> has been replaced by <stdlib.h>"
gmake: *** [output/debug/FCollada/FCollada.o] Error 1

2. How do I modify update-workspaces.sh to run through gmake?

Edited December 8, 2011 by rb1598

[fcxSanya]

Please note that I don't know much about such things, so it is just my dilettantish suppositions.

In file included from FCollada/FUtils/Platforms.h:84,
             	from FCollada/FUtils/FUtils.h:72,
             	from FCollada/FCollada.h:49,
             	from FCollada/StdAfx.h:13,
             	from FCollada/FCollada.cpp:9:
/usr/include/malloc.h:3:2: error: #error "<malloc.h> has been replaced by <stdlib.h>"

If this is common for FreeBSD then in 'FCollada/FUtils/Platforms.h' probably should be a check like:

#ifndef __FreeBSD__
#include <malloc.h>
#endif // __FreeBSD__

2. How do I modify update-workspaces.sh to run through gmake?

As a workaround you can just try change 'make' to 'gmake' in line 47 of 'update-workspaces.sh' (and probably in line 64 too).

Maybe you can do something before calling 'update-workspaces.sh', like turning 'make' into symlink to 'gmake'. It looks like it is not so rare problem (using GNU make files under FreeBSD), so it is better to search what people do in such situations.

[rb1598]

OK, Thanks! I will play around with several alternatives and post result here (probably tomorrow)

Can you offer any input on the dependencies needed on FreeBSD (Q# 1)?

[Ykkrosh]

The best way to find out what dependencies are needed is to try building and see what errors appear about missing libraries . If you need quick feedback on error messages, #0ad-dev QuakeNet IRC is probably the best place to ask. I'm not aware of anybody trying to build on BSD recently so I don't think we can suggest anything specific - just need to try it and see what breaks.

[rb1598]

OK, making some progress...

Got rid of the 1) make 2) malloc.h errors (by modifying the files - not an elegant solution but works for testing)

gmake for fcollada started and ran for some time, but then:

FCollada/FUtils/FUStringBuilder.hpp: In function 'void FloatToString(FloatType, Char*) [with Char = char, FloatType = double]':
FCollada/FUtils/FUStringBuilder.hpp:274:   instantiated from 'void FUStringBuilderT<Char>::append(double) [with Char = char]'
FCollada/FUtils/FUStringBuilder.cpp:102:   instantiated from here
FCollada/FUtils/FUStringBuilder.hpp:37: error: 'ecvt' was not declared in this scope
gmake: *** [output/debug/FCollada/FUtils/FUStringBuilder.o] Error 1
gmake: *** Waiting for unfinished jobs....
ERROR: FCollada build failed

I have done some searching and I cannot find anything about what this error means.

Edited December 9, 2011 by rb1598

[historic_bruno]

Hi, just to add on to the current discussion:

ecvt() is not included in FreeBSD's stdlib.h, as it's an old deprecated POSIX function they have omitted it. So we'd either need to implement it ourselves or rewrite the relevant code with sprintf instead (ecvt() is apparently only used once by fcollada). I found this link which gives a possible implementation. Dropping that code into FUStringBuilder.hpp, at least it finishes building fcollada but I don't know if it works.

Then you need two patches applied to our bundled NVTT 2.0.8-1 (r907 and r1025) which provide FreeBSD support, again I'm not sure how well it works.

The ENet build needs to be told to use gmake instead of make, apparently you can do that by modifying its build script, adding the "SET_MAKE=gmake" option when invoking the configure script.

The next biggest issue is getting premake to work properly. I don't think we have any checks for FreeBSD in our premake scripts (only Linux, OSX/Darwin, and Windows). It may be good enough if all the OSX-specific parts do a test for FreeBSD as well (I notice that's basically how NVTT added FreeBSD support). I did see a few minor issues that are easy to correct: there's no libdl on FreeBSD, so those lines can be removed from Premake4.make (this should be handled by the script that generates this makefile, but for a test, you can alter it by hand). And in premake4.lua, it's not detecting amd64 architecture and defaults to x86, so it needs an additional check for the "amd64" string (both HOSTTYPE and the gcc -dumpmachine hack).

Maybe a Trac ticket referencing all these issues would be helpful

[rb1598]

historic_bruno: Thanks for pitching in.  Re your suggestions, some good news, some not-so-good. First the not-so-good:

1. NVTT 2.0.8-1 (r907 and r1025) are parts of Nvidia tools. I, however am using a radeon card/driver, compiled from latest git repo from DRI/Mesa, which must include the option WITHOUT_NOUVEAU (nvidia) in the make.conf in order to use the latest driver.  It looks like I'll have to take my chances on the graphics engine side...

2. Could not get passed the ecvt block. My "C skills" are negligible, and admittedly all I tried was to dump the linked code at the beginning of (at about line 30) the file  FUStringBuilder.hpp. Where did you place the code in that file?

What worked: Enet builds, thanks for the "SET_MAKE=gmake" tip.

Did not try any of your last paragraph, since it mostly references (if I understood correctly) NVTT workarounds anyway.

Track ticket: Would be more than happy to help, but I have 0 (zero) experience with that - Is the purpose of opening a ticket like a bug report & a developer or team gets assigned to the ticket? Thanks again.

Edited December 11, 2011 by rb1598

[Ykkrosh]

NVTT is developed by NVIDIA but it doesn't require their graphics cards or drivers etc - it's just a standalone library that should work anywhere, so it shouldn't be a problem.

[rb1598]

@ykkrosh: OK - NVTT is in the ports tree: http://www.freshport...a-texture-tools

The depends list does not show any other Nvidia, so that's good. I really wonder if the patch is necessary though, since patch is from Nov&Mar-09, while the latest commit for the port is Nov-11. The patches should be out-dated by now given that NVTT is now natively available from the ports tree.

@historic_bruno: Sometimes my brain locks-up. Re your last paragraph: There is no setting for libld in my Premake4.make, so I guess my system passed good info to some script. For premae4.lua, can you specify where I could just hard-code into the file to set amd64 as default and skip-detects?

I am running on amd64 (stupid I forgot to mention that in 1st post), while c/gcc default on FreeBSD is 4.2. However, I use 4.6 to build my ports/apps (4.2 is reserved by default for base system).

Edited December 11, 2011 by rb1598

[historic_bruno]

1. NVTT 2.0.8-1 (r907 and r1025) are parts of Nvidia tools. I, however am using a radeon card/driver, compiled from latest git repo from DRI/Mesa, which must include the option WITHOUT_NOUVEAU (nvidia) in the make.conf in order to use the latest driver.  It looks like I'll have to take my chances on the graphics engine side...

update-workspaces.sh builds a bundled NVTT in /libraries/nvtt, if you read the README you will see we use the latest release (2.0.8-1 from May 14, 2010), not the SVN trunk, so we do have to apply some patches for various fixes. (What I mean is apply those patches to /libraries/nvtt/, if you examine the source code you'll see the FreeBSD support is not there yet). That said, you may be able to use the NVTT port, if they're compatible, feel free to try this. Then you would just use the --with-system-nvtt flag when running update-workspaces.sh, so it doesn't try to build the bundled copy.

2. Could not get passed the ecvt block. My "C skills" are negligible, and admittedly all I tried was to dump the linked code at the beginning of (at about line 30) the file  FUStringBuilder.hpp. Where did you place the code in that file?

I will try to make a complete patch of all the necessary changes for FreeBSD, because there are many others, but I did get the game to compile into a rather buggy but runnable state.

[historic_bruno]

Mostly the same dependencies are needed as on Linux builds, here's what I had on my test system (only a few needed to be installed by me with "pkg_add -r packagename", because I installed X, Gnome, etc., which already added many dependencies):

GCC 4.2.1 and zlib - included with FreeBSD

sdl

boost-libs

png

execinfo *FreeBSD specific

libxml2

libGL

openal

zip

libogg

libvorbis

curl

gamin

cmake

wxgtk2-unicode

This patch should include all the changes needed to build the game on FreeBSD (I tested on 8.2-Release/amd64), when applied to a clean copy of our SVN trunk:

freebsd_support-12122011.patch

Apply that patch to your working copy and then run ./clean-workspaces.sh followed by ./update-workspaces.sh --without-tests, there's some problem with tests that I didn't bother solving yet.

Actually, contrary to my prior post, the game runs fairly well, though I had to use the Mesa Software Renderer because there is no recent driver available for my Radeon HD 6850 So performance was awful but there were no errors. I should also mention I'm testing this in a VM and couldn't get a sound device configured, so I ran the game with the "-nosound" option to avoid problems.

Atlas worked, which is a bonus.

[rb1598]

Great work - many thanks. FCollada builds without problems.

There is one small new problem however, it's Spidermonkey - fils with:

jsnativestack.o: In function `js::GetNativeStackBaseImpl()':
/asp/s.0ad/libraries/spidermonkey/js-1.8.5/js/src/build-debug/../jsnativestack.cpp:201: undefined reference to `pthread_attr_get_np'
/usr/bin/ld: jsnativestack.o: relocation R_X86_64_PC32 against `pthread_attr_get_np' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
gmake[1]: *** [libmozjs185-ps-debug.so] Error 1
gmake[1]: Leaving directory `/asp/s.0ad/libraries/spidermonkey/js-1.8.5/js/src/build-debug'
gmake: *** [default] Error 2
ERROR: SpiderMonkey build failed

Also, Spidermonkey is already in the native ports structure (lang/spidermonkey). The native port builds fine, but conflicts with an already installed port seamonkey.

[historic_bruno]

Great work - many thanks. FCollada builds without problems.

There is one small new problem however, it's Spidermonkey - fils with:

jsnativestack.o: In function `js::GetNativeStackBaseImpl()':
/asp/s.0ad/libraries/spidermonkey/js-1.8.5/js/src/build-debug/../jsnativestack.cpp:201: undefined reference to `pthread_attr_get_np'
/usr/bin/ld: jsnativestack.o: relocation R_X86_64_PC32 against `pthread_attr_get_np' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
gmake[1]: *** [libmozjs185-ps-debug.so] Error 1
gmake[1]: Leaving directory `/asp/s.0ad/libraries/spidermonkey/js-1.8.5/js/src/build-debug'
gmake: *** [default] Error 2
ERROR: SpiderMonkey build failed

Hmm weird, I didn't get any errors like that Were there any other errors earlier in the build process? The pthread error makes me think it's not properly building against pthread, but I don't know how to test that. What version of FreeBSD are you using?

Edit: it seems you're not the first to encounter this problem, even the SM port has a bug report.

Also, Spidermonkey is already in the native ports structure (lang/spidermonkey). The native port builds fine, but conflicts with an already installed port seamonkey.

Hmm, is the port Spidermonkey 1.8.5? I saw a 1.7 port, which won't work because they change the API so often, it has to be the exact same version (and even then it's not guaranteed to work) :/

[rb1598]

Spidermonkey in ports is ver 1.7.0, so you got me there

even the SM port has a bug report.

My system is FreeBSD 9.0-RC2 on amd64, normally using gcc46 as ports compiler but defaults to base (4.2) when building outside of ports tree (will look into that asap!). I can re-confirm that my system is able to build spidermonkey from ports (1.7) without any problems.

Were there any other errors earlier in the build process?

I cleaned the build directory and re-ran from

0ad/libraries/spidermonkey># ./build.sh

Same result and no errors that I can see..

[historic_bruno]

I cleaned the build directory and re-ran from

0ad/libraries/spidermonkey># ./build.sh

Same result and no errors that I can see..

Can you try one of the fixes suggested in the above link? Try replacing the pthread_np.h include in jsnativestack.cpp:54 with this:

#pragma GCC visibility push(default)
#include <pthread_np.h>
#pragma GCC visibility pop

[historic_bruno]

Also, can some mod move this topic to the technical forum?

[feneur]

Also, can some mod move this topic to the technical forum?

Ah, yeah. It's gotten out of help and feedback and into technical discussion now yeah I will.

[rb1598]

@ historic_bruno: I was busy for a while with building the latest mesa and its depends, among other things.

Placing this in jsnativestack.cpp:54 worked, but I also had to comment out the tar -xzf command in 0ad/libraries/spidermonkey/build.sh, so that it would not over-write the manually made changes.

#pragma GCC visibility push(default)
#include <pthread_np.h>
#pragma GCC visibility pop

After spidermonkey, all other builds completed successfully. Now I have 2 questions:

1. I ran the script as thus, but build did not use GCC46. How can I pass that?

./update-workspaces.sh CC=gcc46 SET_MAKE=gmake

2. To install the build (as per the wiki) # cd gcc && # gmake config=release unfortunately gave:

/source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp: At global scope:
/source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp:62: error: expected `}' at end of input
/usr/X11R6/include/boost/system/error_code.hpp:214: warning: 'boost::system::posix_category' defined but not used
/usr/X11R6/include/boost/system/error_code.hpp:215: warning: 'boost::system::errno_ecat' defined but not used
/usr/X11R6/include/boost/system/error_code.hpp:216: warning: 'boost::system::native_ecat' defined but not used
gmake[1]: *** [obj/atlas_Release/GraphicsSetupHandlers.o] Error 1
gmake: *** [atlas] Error 2

Edited January 4, 2012 by rb1598

[historic_bruno]

After spidermonkey, all other builds completed successfully. Now I have 2 questions:

1. I ran the script as thus, but build did not use GCC46. How can I pass that?

./update-workspaces.sh CC=gcc46 SET_MAKE=gmake

Wouldn't you need to set the environment variables before running the script? The way you're invoking it, I think they will be passed as parameters to the script and discarded.

2. To install the build (as per the wiki) # cd gcc && # gmake config=release unfortunately gave:

/source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp: At global scope:
/source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp:62: error: expected `}' at end of input
It looks like something went wrong applying the patch to that file, I've no idea why that would happen, can you check if it modified the file correctly (it's only two lines difference)?

[rb1598]

set the environment variables before running the script

Yes, you're right - should I set C, CC or LANG to gcc46?

Re the error at GraphicsSetupHandlers.cpp: Actually the error message was longer, my bad:

../../../source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp: In function 'void AtlasMessage::fInitGraphics(AtlasMessage::mInitGraphics*)':
../../../source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp:60: error: expected primary-expression before '<<' token
../../../source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp:60: error: expected primary-expression before '<<' token
../../../source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp:60: error: expected primary-expression before '<<' token
../../../source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp:60: error: expected primary-expression before '<' token
../../../source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp:60: error: expected primary-expression before '.' token
../../../source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp:62: error: expected primary-expression before '||' token
../../../source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp:62: error: expected primary-expression before '||' token
../../../source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp:62: error: expected primary-expression before '|' token
../../../source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp:62: error: expected primary-expression before '.' token
../../../source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp:63: error: expected `;' before '}' token
../../../source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp: At global scope:
../../../source/tools/atlas/GameInterface/Handlers/GraphicsSetupHandlers.cpp:63: error: expected `}' at end of input
/usr/X11R6/include/boost/system/error_code.hpp:214: warning: 'boost::system::posix_category' defined but not used
/usr/X11R6/include/boost/system/error_code.hpp:215: warning: 'boost::system::errno_ecat' defined but not used
/usr/X11R6/include/boost/system/error_code.hpp:216: warning: 'boost::system::native_ecat' defined but not used
gmake[1]: *** [obj/atlas_Release/GraphicsSetupHandlers.o] Error 1
gmake: *** [atlas] Error 2

I checked the file btw and there is no missing "}"

[historic_bruno]

Yes, you're right - should I set C, CC or LANG to gcc46?

At a guess, CC=gcc46 CXX=g++46? I've never done this to know the proper variables. Is there a reason you need to compile with GCC 4.6?

I checked the file btw and there is no missing "}"

Maybe it's a line ending problem introduced by the patch. Try reverting that file and applying the changes by hand in a text editor. Hopefully all the files don't have similar problems.