Not to waste anyone's time, but does anyone know how hard it would be to compile raydium/mania drive in freebsd? I gave it a shot, even though I don't know too much about coding/compiling other than a few scripting languages.As far as I could tell, some issues are joystick libraries (which it seems freebsd is lacking in) and I think the other thing was a realtime clock capability in the linux kernel, which freebsd doesn't have (?).Do you think it is just a matter of those "#ifdef WIN32" type conditions, or is it more than that?

long time ago I'd the same idea, I've tested out many different operating systems including SkyOS, Haiku, OpenBSD and much more. On my operating system trip, the official 3D driver supported ones like FreeBSD and Solaris had at anytime a very special status for me, but for now I've chosen to go the Apple way ... I've no more time to proceed and maintain another Raydium operating system port, but I'll try to help you if you want to start it.

I'm sorry, I've lost my FreeBSD crystal ball , but as far as I can judge this situation it should be not so much changes needed as for example for the Windows or Mac OS X port. I dare say that we can use much parts from the GNU/Linux target, especially the X11 routines. Not really sure about the RTC, but there should be something similar available. For the joystick support we could use some BSD code from PLIB.

First step should check if all dependencies used by Raydium are available for your target operating system.

Please also read the related wiki articles and perhaps the (GNU/Linux) configure script will aspire you in this topic.

mdg583 wrote:

... how hard ... just a matter of those "#ifdef WIN32" type conditions, or is it more than that?

Just try to do it! It's possible to port Raydium and accordingly also ManiaDrive to FreeBSD. In the first step you should check the dependencies as written above. Second step should concentrate on a compilable Raydium library using preprocessor directives wherever needed. Ignore some parts from the engine using e.g. "#ifndef __FreeBSD__", like the Live API and joystick support for now, that don't want to compile. Final step should implement missing parts of the engine under your target operating system.

Best regards,st

Last edited by st on Wed Feb 15, 2012 6:42 pm, edited 1 time in total.

You're welcome. You're pleased to ask questions, so we can try to help you on this, wherever we can.

As ouille said, it shouldn't matter which version you specify. Personally I'd always use and stay at the latest revision and follow the trunk commits, because it's easier to get help from others and it could also a little bit easier to make a patch based on the current revision.

Good luck and have fun! Feel free and don't hesitate to ask questions, I'd really like to see Raydium going FreeBSD.

I have a few questions about how to correctly do things. This may show how little I know about this stuff.Also, mania drive works about 99% in the linuxulator in freebsd. So I don't know how useful it is to compile it in freebsd. I know I would like it, anyway.

Here are some questions:

- include and library directory: does it need to be explicitly set every time?I've had to add '-I/usr/local/include' and '-L/usr/local/lib' to all gcc commands, since files like this are stored in /usr/local in freebsd. What is the best way to deal with this? Is it to use something like this: export C_INCLUDE_PATH='/usr/local/include'? Or to add the -L/usr/local/lib -I/usr/local/include options to gcc commands?

- do I need to download the latest version of php and ode for raydium? Or can I just try to use the ode and php that is already available for freebsd? (from the ports). Chances are ode in the ports will be a little outdated, but I would guess freebsd would try to keep php very up to date.The ports versions are: php 5.2.8, ODE 0.9, curl 7.18.0.

When trying to run the raydium makefile, it says: make: don't know how to make raydium/compile/background.o. Stop. That is from this line in the makefile:

Oh yeah, here are some of the ports versions of the programs you specified above. php is a newer version than required. The ports version of ode and GLEW are older than required. All the others match. I don't know what options were used in compilation. i could figure this out, I suppose, if it is important.

I got a little further. It was pretty easy to add #ifndef __FreeBSD___ in many of the places there is #ifndef __APPLE__, whereever the make of raydium failed. So now I have a compiled libraydium.so, and am trying to see if it is usable.

/usr/bin/ld: warning: libphp5.so, needed by /usr/home/matt/raydium/raydium-2008-12-14//libraydium.so, not found (try using -rpath or -rpath-link)/var/tmp//ccXPLwgS.o(.text+0x71): In function `main':/usr/home/matt/work/test.c:7: undefined reference to `raydium_random_i'

Right now I am just focusing on the fact that libraydium.so is failing to link to libphp5.so. This may have to do with the fact that I did not have raydium fetch and compile a new version of php, but am trying to use the ports version.The libphp5.so is in this location: /usr/local/libexec/apache22/. I am not sure why it is here, rather than the standard /usr/local/lib. It is accompanied by a bunch of mod_*.so files. The line '-L/usr/local/libexec/apache22/' above did not help.Any ideas? Is this a problem in how libraydium.so was compiled?

Gladly to see that you're on it - working hard to port Raydium to FreeBSD.

I know there are ways to execute GNU/Linux binaries on FreeBSD, but let's focus on the native part. Libraries you've installed in a non standard directory, which should be at some common places like e. g. "/usr" and "/urs/local", must be given to the compiler and linker commands. You've also the possibility to create symbolic links or to export the necessary flags, but I'd normally prefer the way to pass the options to the commands.

As mentioned above you should check the configure script which comes with Raydium. Perhaps it'll be useful to get this script running under FreeBSD, because it'll check the availability of the libraries and install some required libraries in the right directories with the required build options. Using the configure script you can see, that on the GNU/Linux target the stable version of ODE is always 0.7 and the latest snapshot version of PHP is always 5.2. The dependency list above is an example to see what is used under Mac OS X. You can use your preferred port system to get the needed packages, but be sure to obtain them with at least the build options that Raydium requires. For example ODE needs to be build without double precision, so be sure that it was build using single precision. That is one reason I've posted the dependency list with the build options, but the list doesn't include the minimum library versions required. Using the versions included within the list works and using lower or higher versions could work. So, the libraries you've posted should work, regarding they were build with the options needed by Raydium. There are also port systems available for Mac OS X, e. g. MacPorts, but I'm building the needed libraries myself manually to have maximum control over the build options.

Regarding to your modification on the Makefile, I can only say that you have to modify whatever needed to reach our goal, to get Raydium natively running under FreeBSD. Good job!

While reading your last post, I've to think about the PHP module for Apache. I don't really know if you can use the Apache module version of PHP for Raydium. To exclude this issue, you're pleased to try a method written above. To get the configure script up and running or to build the library manually yourself from scratch, to obtain a new, adapted version of PHP which exactly matches the Raydium requirements.Perhaps it'll be easier to make tests, using (modified versions of) the GNU/Linux compile scripts and some "official" test files like e. g. "./odyncomp.sh test6.c".

I've found a problem was that I was trying to statically link the file libphp.so, which is a dynamic library, rather than a libphp.a file. But libphp.a isn't build by php by default - the mania drive configure script gave the option for it(--enable-embed=static --with-zlib --enable-static=zlib).

Just to try to get things working, I've modified the ports version of php to have some of the options in the configure script, including those above.)

-- now test6.c compiles, but running it gives a segfault...

I am a bit wary of just getting and compiling php and ode, because to do so requires a bunch of patched, which are provided by the ports system (as far as I can tell.)

I've started to try using gdb to find out why it is segfaulting and I was wondering if you could help me with something?

I am sure the segfault I mentioned above had nothing to do with libraydium or my test program - it had to do with the dynamicly linked libraries. (I tried compiling a failsafe .c file into a library with the raydium compile options and then linking to it with a test program, and it failed the same way).

So after this I made an empty program and compiled it against all the shared libraries libraydium is compiled against, and get the following:

/usr/bin/ld: warning: libm.so.3, needed by /usr/X11R6/lib//libGL.so, may conflict with libm.so.5

It seems my nvidia drivers installed a compat5x package which contains freebsd5 libraries for compatability, and places them in /usr/local/lib/compat (link, same as below). So I have 2 versions of libm.so.5: one in /usr/lib, and one in /usr/local/compat/libm.so.3.

Now here is my question: how to I specify to the compiler to try to link raydium against /usr/local/compat/libm.so.3 rather than /usr/lib/libm.so.5? Or is this a bad idea?

On the other hand, it could be this is not what is causing the segfault.This seems more likely to me right now.

I think some other of the linked libraries depend on libm.so.5 - if I remove -lm in the above test, ldd shows the program is still lining to /usr/lib/libm.so.5. Some people mention this issue here.

I put #ifndef NO_SOUND_DEBUG around every call to a function in sound.c, and wrapped it around all of sound.c. Then I commented out all calls to sound functions in test6.c, built raydium without -lopenal or -lalut, and everything else seems to be working!

I am going to post the openal and libGL linking problem on nvidia forums - I am wondering if their libGL is at fault.

I commented out all raydium_sound functions from mania_drive.c - and it is working for me too.

It works exactly the same as in the linuxulator. It has an occasional lag (about .1 to .5 seconds every 4 or 5 seconds). It shows a much lower fps than in the linuxulator - maybe it could easily be that the linuxulator version doesn't show the fps right?

In the linuxulator it shows 500 fps. The one I have compiled in freebsd shows 100 fps.It could also be that the linux binary version I have is the stable one that was released, and the compiled version is the unstable version.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum