It looks like you're new here. If you want to get involved, click one of these buttons!
g++ -D__orxSTATIC__ -g base/*.c render/*.c object/*.c display/*.c core/*.c memory/*.c math/*.c utils/*.c io/*.c plugin/*.c sound/*.c physics/*.c anim/*.c debug/*.c ../../tutorial/src/10_StandAlone/10_StandAlone.cpp main/orxParam.c ../plugins/Display/SFML/orxDisplay.cpp ../plugins/Keyboard/SFML/orxKeyboard.cpp ../plugins/Sound/SFML/orxSoundSystem.cpp ../plugins/Render/Home/orxRender.c ../plugins/Mouse/SFML/orxMouse.cpp -I../include -I../../extern/dlmalloc/ -lm -ldl -o ../../tutorial/bin/linux/10_StandAlone -lsfml-audio -lsfml-graphics -lsfml-window -lsfml-system
/tmp/ccaU0CTZ.o: In function `orxPlugin_MainInit':
/home/username/devel/orx_svn/orx/trunk/code/src/../plugins/Keyboard/SFML/orxKeyboard.cpp:436: multiple definition of `orxPlugin_MainInit'
/tmp/cc26fvXc.o:/home/username/devel/orx_svn/orx/trunk/code/src/../plugins/Display/SFML/orxDisplay.cpp:1877: first defined here
/tmp/ccYUyuiO.o: In function `orxPlugin_MainInit':
/home/username/devel/orx_svn/orx/trunk/code/src/../plugins/Sound/SFML/orxSoundSystem.cpp:831: multiple definition of `orxPlugin_MainInit'
/tmp/cc26fvXc.o:/home/username/devel/orx_svn/orx/trunk/code/src/../plugins/Display/SFML/orxDisplay.cpp:1877: first defined here
Comments
I'd suggest you try to build it in two steps: first the orx library then using it as link time on the tutorial.
For that you need to compile orx as a static library using the __orxSTATIC__ define, as you did, and also the __orxEMBEDDED__ so that all the plugins will be correctly mapped internally at compile time. I can't remember the symbol export settings (maybe they're all visible by default, not sure, I need to check the build file so as to remember).
When you have liborx.a you simply need to link the tutorial against it (the tutorial only needs __orxSTATIC__, not __orxEMBEDDED__) by adding -lorx as a link parameter.
Please note that when using the static version you can only use the SFML plugins (but I guess you already know that) and those plugins are leff efficient and provide some non-standard features (mostly shaders) whereas the GLFW plugins are more robust and fast but can only be used in the dynamic version (your exe + orx.so).
Hope this helps!
* edit : You can have a look at the codelite project files, even using a simple text editor, to find out about all the command line parameters for the static version. Also please note that I can't compile it in release on my linux as my gcc version is buggy and crashes when trying to make some optims, leaving me with no choice than staying at -O1 instead of -O2/-O3. *
There's a dummy joystick plugin that doesn't do anything but there isn't such a thing for the physics plugin (you'll need either to compile the Box2D one or to write a quick empty physics plugin).
May I ask for what use you need such a stripped down/static version?
I also had trouble with gcc 4.4 and I found you comment on the home page, so I'm now using gcc 4.3.
I was trying to avoid Box2D in order to keeps things small, but I guess I'll compile it anyway.
I'm trying to compile orx this way because I want to use it in a system with a limited build system.
By the way, what is the preferred way to send patches? I had to edit orxDefaultFont.c in order to include orxDisplay.h
I haven't tried on linux yet but, with mingw, things look better with gcc 4.5.0.
There are other ways if you want, they are simply a bit more intrusive. If Box2D is really a problem, let me know, I'll make a list of changes to do on the embedded version so as to skip the physics plugin completely. In the non-embedded version, it's easier as all you have to do is not load the physics plugin.
As you're going for embedded anyway, I'd suggest you use the GLFW plugins instead of SFML. The only reason why I haven't gotten completely read of the SFML plugins is that because GLFW currently can't be used in multiple DLLs loaded at runtime.
You can send me a diff. When people make big changes I usually give them access to the svn and create a branch for them.
As for the include: you're actually not supposed to compile orxDefaultFont.c, the file is included from the font module and only contains data. I should probably change its extension as it's misleading.
I'm using the codelite template for linux and that is working fairly well if you want to go down that route as opposed to g++ from the command line.
I'll check the codelite files (I installed codelite to use them, but didn't open them in a text editor). However I'm not interested in building orx with an external program, I want to be able to compile it myself. Unfortunately I don't have much free time lately. Maybe after Christmas.