Compiling SPARK 2 on Gentoo Linux

Messages : 7 Date d'inscription : 2011-12-29

Hi there. I just checked out the latest revision of SPARK 2 from the SVN repository.
I fixed most of the compile errors, but I have two left which have me a bit puzzled.

Once I get the library compiling and test it I can check in the changes... so far they are minor and involve things where GCC is more strict than the MSVC compiler.

Anyway, here are the errors:

Code:: ~/projects/spark_allegro/spark/include/Core/SPK_Zone.h:70:117: error: default argument for parameter of type ‘SPK::Vector3D&’ has type ‘SPK::Vector3D’
~/projects/spark_allegro/spark/include/Core/SPK_Zone.h:79:89: error: default argument for parameter of type ‘SPK::Vector3D&’ has type ‘SPK::Vector3D’

And the two lines in question from SPK_Zone.h:

Code:: (line 70) virtual bool intersects(const Vector3D& v0,const Vector3D& v1,float radius = 0.0f,Vector3D& normal = Vector3D()) const = 0;
(line 79) bool check(const Particle& particle,ZoneTest zoneTest,Vector3D& normal = Vector3D()) const;

Developer Messages : 539 Date d'inscription : 2009-07-14 Age : 42

Hi,

I compiled SPARK under GCC recently (not the last version of the compiler though). Which version of gcc are you using ?

For the issue, it is a problem with Rvalue bound to non const reference. The default value is uniquely used when the normal doesnt need to be read back but it is not really legal (even though VSC does not complain)

The best way to solve the problem would be to replace the non const reference by a pointer with a NULL default value and test the nullity when needed inside the method implementations. The quick hack would be to have a static vector used as a dummy and pass it as the default value to the method. I used that last method in ZoneModifier because gcc was complaining but it is strange it didnt complain for me in Zone.h

What are the other stuff you re talking about you had to modify in the code for it to compile under GCC ?

Messages : 7 Date d'inscription : 2011-12-29

Yea I realize trying to set a default argument for a non-const reference parameter is illegal, but making the parameters const caused more problems, heh.

The other changes I made are in this diff:

Code:: Index: include/Core/SPK_Iterator.h
===================================================================
--- include/Core/SPK_Iterator.h (revision 336)
+++ include/Core/SPK_Iterator.h (working copy)
@@ -132,67 +132,79 @@
   template<typename T>
   inline bool operator!=(const Iterator<T>& it0,const ConstIterator<T>& it1) { return it0->getIndex() != it1->getIndex(); }

+ template <>
   inline Iterator<Group>::Iterator(Group& group) :
      particle(group,0)
   {
      SPK_ASSERT(group.isInitialized(),"Iterator::Iterator(Group&) - An iterator from an uninitialized group cannot be retrieved");
   }

+ template <>
   inline Particle& Iterator<Group>::operator*() const
   {
      return particle;
   }
-
+
+ template <>
   inline Particle* Iterator<Group>::operator->() const
   {
      return &particle;
   }

+ template <>
   inline Iterator<Group>& Iterator<Group>::operator++()
   {
      ++particle.index;
      return *this;
   }

+ template <>
   inline Iterator<Group> Iterator<Group>::operator++(int)
   {
      Iterator tmp(*this);
      return ++tmp;
   }

+ template <>
   inline bool Iterator<Group>::end() const
   {
      return particle.index >= particle.group.getNbParticles();
   }

+ template <>
   inline ConstIterator<Group>::ConstIterator(const Group& group) :
      particle(const_cast<Group&>(group),0)
   {
      SPK_ASSERT(group.isInitialized(),"ConstIterator::ConstIterator(Group&) - An const iterator from a uninitialized group cannot be retrieved");
   }

+ template <>
   inline const Particle& ConstIterator<Group>::operator*() const
   {
      return particle;
   }
-
+
+ template <>
   inline const Particle* ConstIterator<Group>::operator->() const
   {
      return &particle;
   }

+ template <>
   inline ConstIterator<Group>& ConstIterator<Group>::operator++()
   {
      ++particle.index;
      return *this;
   }

+ template <>
   inline ConstIterator<Group> ConstIterator<Group>::operator++(int)
   {
      ConstIterator tmp(*this);
      return ++tmp;
   }

+ template <>
   inline bool ConstIterator<Group>::end() const
   {
      return particle.index >= particle.group.getNbParticles();
Index: include/Core/IO/SPK_IO_Descriptor.h
===================================================================
--- include/Core/IO/SPK_IO_Descriptor.h (revision 336)
+++ include/Core/IO/SPK_IO_Descriptor.h (working copy)
@@ -31,6 +31,8 @@

namespace IO
{
+ class Attribute;
+
   /**
   * @brief A description of a SPKObject for serialization/deserialization
   *

Originally I wanted to start writing a renderer for the Allegro 5 library, but I want to get this all working first.

EDIT:
Whoops forget to let you know my GCC version: gcc (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) 4.5.3

Developer Messages : 539 Date d'inscription : 2009-07-14 Age : 42

Ok thanks,
I will push a revision on SVN in a few hours that should address all these issues.
I ll let you know when its done

Messages : 7 Date d'inscription : 2011-12-29

I found one more small issue (I included the explanation):

Code:: Index: include/Core/IO/SPK_IO_Descriptor.h
===================================================================
--- include/Core/IO/SPK_IO_Descriptor.h (revision 336)
+++ include/Core/IO/SPK_IO_Descriptor.h (working copy)
@@ -31,6 +31,8 @@

namespace IO
{
+ class Attribute;
+
   /**
   * @brief A description of a SPKObject for serialization/deserialization
   *
@@ -44,7 +46,22 @@
   class SPK_PREFIX Descriptor
   {
   friend class Attribute;
- friend class SPKObject;
+ friend class SPK::SPKObject;
+
+ /*
+ *
+ * Friends of classes defined outside their namespace are correctly handled:
+ * namespace N {
+ * class A;
+ * }
+ * class N::A {
+ * friend class B; // Refer to N::B in GCC 4.0.0
+ * // but ::B in earlier versions of GCC
+ * };
+ * }
+ * }
+ */

   public :

Other than that there are just a lot of errors having to do with the default Vector3D arguments. I don't think it's a good idea to just go through your code and put static Vector3Ds everywhere, but then if I change it to take a pointer I'm not sure how much code that's going to affect. I'm assuming a lot.

Developer Messages : 539 Date d'inscription : 2009-07-14 Age : 42

Ok I pushed the changes on SVN (including Vector3D& transformed to Vector3D*)
Tell me if there's still some trouble

Messages : 7 Date d'inscription : 2011-12-29

You fixed everything except one:

Code:: Index: src/Core/SPK_Group.cpp
===================================================================
--- src/Core/SPK_Group.cpp (revision 338)
+++ src/Core/SPK_Group.cpp (working copy)
@@ -764,7 +764,7 @@

      prepareAdditionnalData();

-    unsigned int nbManualBorn = nbBufferedParticles;
+    size_t nbManualBorn = nbBufferedParticles;

      size_t dummy;
      while (nbManualBorn > 0 && particleData.maxParticles - particleData.nbParticles > 0)

Anyway, I'm now having an issue with it not being able to link the pugixml library. I'll keep working on fixing it but here are the errors for now.

Code:: /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: ~/projects/spark_allegro/spark/projects/engine/build/pugixml/libpugixml.a(pugixml.cpp.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
~/projects/spark_allegro/spark/projects/engine/build/pugixml/libpugixml.a: could not read symbols: Bad value
collect2: ld returned 1 exit status

EDIT:
Solved it by passing CMAKE_CXX_FLAGS="-fPIC"
This is apparently required on x86_64 machines.

I think it can be added to the cmake file like this (I'm not really sure, I don't have much experience with cmake):

Code:: IF("${CMAKE_SYSTEM_PROCESSOR}" STREQUAL "x86_64")
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC" )
ENDIF("${CMAKE_SYSTEM_PROCESSOR}" STREQUAL "x86_64")

Messages : 7 Date d'inscription : 2011-12-29

Well your SPARK engine is now compiling nicely.
The OpenGL renderer is not compiling (quite a few strange errors), but at least I can start on the Allegro renderer now, although I'd like to get the GL renderer working as well.

If you have any idea what might cause all these errors, let me know, heh.

Code:: In file included from /usr/include/GL/glext.h:5105:0,
from /usr/include/GL/gl.h:2091,
from ~/projects/spark_allegro/spark/include/Rendering/OpenGL/SPK_GL_DEF.h:50,
from ~/projects/spark_allegro/spark/include/Rendering/OpenGL/SPK_GL_Renderer.h:25,
from ~/projects/spark_allegro/spark/include/Rendering/OpenGL/SPK_GL_LineRenderer.h:25,
from ~/projects/spark_allegro/spark/src/Rendering/OpenGL/SPK_GL_LineRenderer.cpp:23:
/usr/include/inttypes.h:298:8: error: ‘intmax_t’ does not name a type
/usr/include/inttypes.h:301:27: error: ‘intmax_t’ was not declared in this scope
/usr/include/inttypes.h:301:45: error: ‘intmax_t’ was not declared in this scope
/usr/include/inttypes.h:302:7: error: expected ‘,’ or ‘;’ before ‘throw’
/usr/include/inttypes.h:305:8: error: ‘intmax_t’ does not name a type
/usr/include/inttypes.h:309:8: error: ‘uintmax_t’ does not name a type
/usr/include/inttypes.h:313:8: error: ‘intmax_t’ does not name a type
/usr/include/inttypes.h:318:8: error: ‘uintmax_t’ does not name a type
In file included from /usr/include/GL/gl.h:2091:0,
from ~/projects/spark_allegro/spark/include/Rendering/OpenGL/SPK_GL_DEF.h:50,
from ~/projects/spark_allegro/spark/include/Rendering/OpenGL/SPK_GL_Renderer.h:25,
from ~/projects/spark_allegro/spark/include/Rendering/OpenGL/SPK_GL_LineRenderer.h:25,
from ~/projects/spark_allegro/spark/src/Rendering/OpenGL/SPK_GL_LineRenderer.cpp:23:
/usr/include/GL/glext.h:5111:9: error: ‘uint64_t’ does not name a type
/usr/include/GL/glext.h:5116:9: error: ‘uint64_t’ does not name a type
In file included from /usr/include/GL/gl.h:2091:0,
from ~/projects/spark_allegro/spark/include/Rendering/OpenGL/SPK_GL_DEF.h:50,
from ~/projects/spark_allegro/spark/include/Rendering/OpenGL/SPK_GL_Renderer.h:25,
from ~/projects/spark_allegro/spark/include/Rendering/OpenGL/SPK_GL_LineRenderer.h:25,
from ~/projects/spark_allegro/spark/src/Rendering/OpenGL/SPK_GL_LineRenderer.cpp:23:
/usr/include/GL/glext.h:6696:84: error: ‘GLuint64’ has not been declared
/usr/include/GL/glext.h:6697:76: error: ‘GLuint64’ has not been declared
/usr/include/GL/glext.h:6845:81: error: ‘GLuint64’ has not been declared
In file included from /usr/include/GL/gl.h:2091:0,
from ~projects/spark_allegro/spark/include/Rendering/OpenGL/SPK_GL_DEF.h:50,
from ~/projects/spark_allegro/spark/include/Rendering/OpenGL/SPK_GL_Renderer.h:25,
from ~/projects/spark_allegro/spark/include/Rendering/OpenGL/SPK_GL_LineRenderer.h:25,
from ~/projects/spark_allegro/spark/src/Rendering/OpenGL/SPK_GL_LineRenderer.cpp:23:
/usr/include/GL/glext.h:9699:84: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10050:75: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10051:78: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10055:85: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10690:102: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10744:91: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10745:96: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10746:68: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10747:66: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10748:88: error: ‘GLuint64EXT’ does not name a type
/usr/include/GL/glext.h:10749:86: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10750:89: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10751:111: error: ‘GLuint64EXT’ does not name a type
/usr/include/GL/glext.h:10770:85: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10781:84: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10897:67: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10898:67: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10898:82: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10899:67: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10899:82: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10899:97: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10900:67: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10900:82: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10900:97: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10900:112: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10901:89: error: ‘GLuint64EXT’ does not name a type
/usr/include/GL/glext.h:10902:89: error: ‘GLuint64EXT’ does not name a type
/usr/include/GL/glext.h:10903:89: error: ‘GLuint64EXT’ does not name a type
/usr/include/GL/glext.h:10904:89: error: ‘GLuint64EXT’ does not name a type
/usr/include/GL/glext.h:10914:90: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10915:90: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10915:105: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10916:90: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10916:105: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10916:120: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10917:90: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10917:105: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10917:120: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10917:135: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10918:112: error: ‘GLuint64EXT’ does not name a type
/usr/include/GL/glext.h:10919:112: error: ‘GLuint64EXT’ does not name a type
/usr/include/GL/glext.h:10920:112: error: ‘GLuint64EXT’ does not name a type
/usr/include/GL/glext.h:10921:112: error: ‘GLuint64EXT’ does not name a type
/usr/include/GL/glext.h:10963:71: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10964:71: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10964:86: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10965:71: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10965:86: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10965:101: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10966:71: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10966:86: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10966:101: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10966:116: error: ‘GLuint64EXT’ has not been declared
/usr/include/GL/glext.h:10967:78: error: ‘GLuint64EXT’ does not name a type
/usr/include/GL/glext.h:10968:78: error: ‘GLuint64EXT’ does not name a type
/usr/include/GL/glext.h:10969:78: error: ‘GLuint64EXT’ does not name a type
/usr/include/GL/glext.h:10970:78: error: ‘GLuint64EXT’ does not name a type
/usr/include/GL/glext.h:10972:88: error: ‘GLuint64EXT’ has not been declared

Developer Messages : 539 Date d'inscription : 2009-07-14 Age : 42

Yes, it is a conflict due to a custom stdint.h definition I m using in the project.
Anyway, I dont really need it, so I used a simpler way to define fixed size integer.
Try the latest revision on SVN.

Messages : 7 Date d'inscription : 2011-12-29

Okay I have everything building. Thanks for all your help.

Here are a few more changes for you:

Code:: Index: include/Rendering/OpenGL/SPK_GL_DEF.h
===================================================================
--- include/Rendering/OpenGL/SPK_GL_DEF.h (revision 340)
+++ include/Rendering/OpenGL/SPK_GL_DEF.h (working copy)
@@ -27,13 +27,22 @@
#endif

#ifdef SPK_GL_EXPORT
+
+#if defined(WIN32) || defined(_WIN32)
+
+#ifdef SPK_GL_EXPORT
#define SPK_GL_PREFIX __declspec(dllexport)
#elif defined(SPK_IMPORT) || defined(SPK_GL_IMPORT)
-#define SPK_GL_PREFIX __declspec(dllimport)
+#define SPK_GL_PREFIX __declspec(dllimport)
+#endif
+
+// dllexport and dllimport are not needed on linux or mac
#else
#define SPK_GL_PREFIX
#endif

+// still needs to be defined even if SPK_GL_EXPORT is not
+#else
+#define SPK_GL_PREFIX
+#endif
+
#ifndef SPK_NO_GL_INC

#if defined(WIN32) || defined(_WIN32)

Also in the OpenGL renderer CMakeLists file you are linking with "opengl32" but it should be "GL" on linux (adding a simple OS check would fix that).

One more thing I noticed was the location the library files were placed and the location the CMake files looked for the libraries were different. I ended up doing this temporarily:

Code:: Index: projects/engine/ogl/CMakeLists.txt
===================================================================
--- projects/engine/ogl/CMakeLists.txt (revision 340)
+++ projects/engine/ogl/CMakeLists.txt (working copy)
@@ -35,13 +35,15 @@
add_definitions(-DGLEW_STATIC)
include_directories(${SPARK_DIR}/include)
include_directories(${SPARK_DIR}/external/glew/src)
-link_directories(${SPARK_DIR}/external/glew/bin)
+#link_directories(${SPARK_DIR}/external/glew/bin)
+link_directories(${SPARK_DIR}/projects/engine/build/glew)
if(${SPARK_STATIC_BUILD})
   set(SPARK_OUTPUT_TYPE static)
else()
   set(SPARK_OUTPUT_TYPE dynamic)
endif()
-link_directories(${SPARK_DIR}/lib/${SPARK_GENERATOR}/${SPARK_OUTPUT_TYPE})
+#link_directories(${SPARK_DIR}/lib/${SPARK_GENERATOR}/${SPARK_OUTPUT_TYPE})
+link_directories(${SPARK_DIR}/projects/engine/build/core)
if(${SPARK_STATIC_BUILD})
   add_library(SPARK_OpenGL STATIC ${SRC_FILES})
else()
@@ -52,7 +54,8 @@
   debug SPARK_debug
   optimized glew
   optimized SPARK
- general opengl32
+ #general opengl32
+ general GL
)
set_target_properties(SPARK_OpenGL PROPERTIES
   OUTPUT_NAME SPARK_GL
Index: projects/engine/core/CMakeLists.txt
===================================================================
--- projects/engine/core/CMakeLists.txt (revision 340)
+++ projects/engine/core/CMakeLists.txt (working copy)
@@ -62,7 +62,8 @@
add_definitions(-DSPK_CORE_EXPORT)
include_directories(${SPARK_DIR}/include)
include_directories(${SPARK_DIR}/external/pugixml/src)
-link_directories(${SPARK_DIR}/external/pugixml/bin)
+#link_directories(${SPARK_DIR}/external/pugixml/bin)
+link_directories(${SPARK_DIR}/projects/engine/build/pugixml)
if(${SPARK_STATIC_BUILD})
   set(SPARK_OUTPUT_TYPE static)
   add_library(SPARK_Core STATIC ${SRC_FILES})

Anyway, those are all minor things.
Thanks again for your help, although I might need a bit more help getting my renderer working, I'll see. Very Happy

EDIT:
I got the OpenGL demo working as well.

Compiling SPARK 2 on Gentoo Linux Spark_demo

Subject: Re: Compiling SPARK 2 on Gentoo Linux Wed Jan 04, 2012 2:38 pm

Thank you for the report on CMake issues, especially for the 64bit linux related one. I will push the modifications asap.
I will test a 64bit build on my machine, for the moment I'm on Windows 64bit but only compile in 32 bit...

EDIT: The commit I will push will move VC++ and C::B projects in a "deprecated" folder, for final deletion.

Subject: Re: Compiling SPARK 2 on Gentoo Linux Thu Jan 05, 2012 1:06 pm

I've pushed only 3 modifications:
- moving the old projects
- changing the lib name of OpenGL to user-specified. By default, it will take the value 'opengl32' on all platforms except on Linux, where it is defaulted to 'GL'.
- Fixed errors occurring when no Irrlicht lib names are given to CMake.

For the inconsistent library paths, I don't see the source of the problem. Everything works well on Windows 32/64 bit, I've tested it on 3 machines. I currently don't have a Linux machine...
What is your build toolchain ?

Messages : 7 Date d'inscription : 2011-12-29

Thanks for the help.
The inconsistent library paths are my fault. I assumed CMAKE_BUILD_TYPE was already set to some default, but it's not (which makes sense), so once I set it myself it works fine, haha.

I fixed I posted above for the 64bit issues does work since I just tested it.

Code:: IF("${CMAKE_SYSTEM_PROCESSOR}" STREQUAL "x86_64")
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fPIC")
SET(CMAKE_C_FLAGS "${CMAKE_CXX_FLAGS} -fPIC")
ENDIF("${CMAKE_SYSTEM_PROCESSOR}" STREQUAL "x86_64")

Although that probably only works for GCC. I'm not sure about the MSVC compiler.

» Compiling error in linux
» Compiling SPARK on Mac OS X
» Problems compiling SPARK with SFML on VC++ 2008 EE
» SPARK2 Slow linking and compiling
» Compiling SPARK2 and DX9 causes bunch of errors