Horde3D
http://horde3d.org/forums/

Compiling on 64-bit Linux
http://horde3d.org/forums/viewtopic.php?f=3&t=939		 Page 1 of 1
Author:  cefwyn [ 08.09.2009, 17:00 ]
Post subject:  Compiling on 64-bit Linux
I was surprised at how easily Horde3D compiles on 64-bit Linux considering how much effort it was with older versions. There is however one issue which is pretty easy to fix and I didn't see it mentioned on this forum.

In the file egShader.cpp at around line 266 in the class Tokenizer:
Code:
static const int tokenSize = 128;

should be
Code:
static const long tokenSize = 128;

otherwise you will probably get errors around line 339 and 340 from this bit of code:
Code:
std::min( _p - p0, tokenSize-1 )

because _p - p0 becomes a long int, while tokenSize-1 is an int and apparently GCC 64-bit doesn't like that.

To maintain 64-bit compliance without breaking 32-bit support it's pretty easy to just replace int with long when not dealing with pointers since on 32-bit they are identical width datatypes on most architectures and on 64-bit a long is usually what the programmer is really wanting when they type "int". It does get a bit messy though as on Windows "int" and "long" are identical even on 64-bit so they are both 32-bit datatypes but on Linux int is 32-bit and long is 64-bit, but since most of the stl code like std::min use long in place of int, long is the safer bet and just means more accuracy on 64-bit linux.
Author:  marciano [ 08.09.2009, 21:52 ]
Post subject:  Re: Compiling on 64-bit Linux
Thanks a lot for the hint, the line you mention needs to be fixed.

When using int, I always assume 32 bits, even on 64 bit systems. I would not replace int32 by long in general because usually you don't need the additional bits and in that case long64 would just waste memory and worsen the cache behavior.
Author:  cefwyn [ 09.09.2009, 19:36 ]
Post subject:  Re: Compiling on 64-bit Linux
Yeah, if your really wanting a 32-bit int then that line should remain as it is, but unfortunately much of STL appears to use long in place of int and so you need to at least type-cast to long when passing to std::min just so it doesn't confuse the compiler.
Author:  mihai [ 02.10.2009, 19:31 ]
Post subject:  Re: Compiling on 64-bit Linux
I have the following problem when building on Linux 64 (Arch):
Code:
/home/mihai/builds/Horde3D/Horde3D_SDK_1.0.0_Beta4/Horde3D/Source/Horde3DEngine/egRenderer.cpp: In member function ‘unsigned char* Renderer::useScratchBuf(uint32)’:
/home/mihai/builds/Horde3D/Horde3D_SDK_1.0.0_Beta4/Horde3D/Source/Horde3DEngine/egRenderer.cpp:94: error: ‘uintptr_t’ was not declared in this scope
/home/mihai/builds/Horde3D/Horde3D_SDK_1.0.0_Beta4/Horde3D/Source/Horde3DEngine/egRenderer.cpp:94: error: expected ‘;’ before ‘_scratchBuf’
/home/mihai/builds/Horde3D/Horde3D_SDK_1.0.0_Beta4/Horde3D/Source/Horde3DEngine/egRenderer.cpp:94: error: invalid operands of types ‘unsigned char*’ and ‘int’ to binary ‘operator%’
Author:  marciano [ 03.10.2009, 10:28 ]
Post subject:  Re: Compiling on 64-bit Linux
Could you check where (in which header) uintptr_t is defined on your system? Actually the whole statement could be reduced to "return _scratchBuf;". The rest is just to align the pointer to 16 bytes so that memory accesses are a little faster (at least in theory).
Author:  mihai [ 03.10.2009, 11:59 ]
Post subject:  Re: Compiling on 64-bit Linux
marciano wrote:
Could you check where (in which header) uintptr_t is defined on your system? Actually the whole statement could be reduced to "return _scratchBuf;". The rest is just to align the pointer to 16 bytes so that memory accesses are a little faster (at least in theory).

I know most of these results are unrelated to your question, but maybe something can ring a bell.
Code:
$ grep -nrHE *typedef.+uintptr_t\;+ /usr/include
/usr/include/sofia-sip-1.12/sofia-sip/su_types.h:79:typedef unsigned SU_INTPTR_T uintptr_t;
/usr/include/caca_types.h:85:typedef unsigned long int _caca_uintptr_t;
/usr/include/xulrunner-1.9.1/unstable/qcmstypes.h:29:typedef PRUptrdiff uintptr_t;
/usr/include/xulrunner-1.9.1/unstable/qcmstypes.h:67:typedef unsigned __int64 uintptr_t;
/usr/include/xulrunner-1.9.1/unstable/qcmstypes.h:69:typedef unsigned long uintptr_t;
/usr/include/xulrunner-1.9.1/unstable/jsstdint.h:66:typedef unsigned JS_INTPTR_TYPE uintptr_t;
/usr/include/boost/test/impl/execution_monitor.ipp:82:    typedef unsigned uintptr_t;
/usr/include/boost/test/impl/execution_monitor.ipp:86:typedef void* uintptr_t;
/usr/include/wine/msvcrt/crtdefs.h:101:typedef unsigned __int64 uintptr_t;
/usr/include/wine/msvcrt/crtdefs.h:103:typedef unsigned int uintptr_t;
/usr/include/c++/4.4.1/stdatomic.h:112:  typedef atomic_ulong       atomic_uintptr_t;
/usr/include/apr-1/apr.h:292:typedef  apr_uint64_t            apr_uintptr_t;
/usr/include/apr-1/apr.h:294:typedef  apr_uint32_t            apr_uintptr_t;
/usr/include/python2.6/pyport.h:89:typedef uintptr_t   Py_uintptr_t;
/usr/include/python2.6/pyport.h:93:typedef unsigned int   Py_uintptr_t;
/usr/include/python2.6/pyport.h:97:typedef unsigned long   Py_uintptr_t;
/usr/include/python2.6/pyport.h:101:typedef unsigned PY_LONG_LONG   Py_uintptr_t;
/usr/include/gc/gc.h:1046:     typedef unsigned long uintptr_t;
/usr/include/php/TSRM/TSRM.h:37:typedef unsigned __int64 tsrm_uintptr_t;
/usr/include/php/TSRM/TSRM.h:40:typedef unsigned long tsrm_uintptr_t;
/usr/include/php/Zend/zend_types.h:47:typedef unsigned __int64 zend_uintptr_t;
/usr/include/php/Zend/zend_types.h:50:typedef unsigned long zend_uintptr_t;
/usr/include/stdint.h:123:typedef unsigned long int   uintptr_t;
/usr/include/stdint.h:129:typedef unsigned int      uintptr_t;

The code in the last file is:
Code:
/* Types for `void *' pointers.  */
#if __WORDSIZE == 64
# ifndef __intptr_t_defined
typedef long int      intptr_t;
#  define __intptr_t_defined
# endif
typedef unsigned long int   uintptr_t;
#else
# ifndef __intptr_t_defined
typedef int         intptr_t;
#  define __intptr_t_defined
# endif
typedef unsigned int      uintptr_t;
#endif
Author:  phoenix64 [ 04.10.2009, 00:02 ]
Post subject:  Re: Compiling on 64-bit Linux
This is how I just got horde3d to compile on 64bit ubuntu karmic. Everything except including stdint.h (header for uintptr_t) should be safe on all other platforms I can think of. There you can use some hack though like ifndef-ing for MSC_VER around it.

stdint.h however is *not* available on msvc as they don't support C99 (hey - that was 10 years ago -.-).

The thing about stdio.h is about sprintf not being found when using gcc 4.4.

Code:
Index: Extensions/Terrain/Sample/main.cpp
===================================================================
--- Extensions/Terrain/Sample/main.cpp   (Revision 193)
+++ Extensions/Terrain/Sample/main.cpp   (Arbeitskopie)
@@ -19,6 +19,7 @@
 #include <iostream>
 #include <cstdlib>
 #include <cstring>
+#include <cstdio>
 #include "glfw.h"
 #include "app.h"
 
Index: Horde3D/Source/Horde3DEngine/egShader.cpp
===================================================================
--- Horde3D/Source/Horde3DEngine/egShader.cpp   (Revision 193)
+++ Horde3D/Source/Horde3DEngine/egShader.cpp   (Arbeitskopie)
@@ -335,8 +335,8 @@
       const char *p0 = _p;
       seekChar( " \t\n\r{}()<>=,;" );  // Advanve until whitespace or special char found
       if( _p == p0 && *_p != '\0' ) ++_p;  // Handle special char
-      memcpy( _token, p0, std::min( _p - p0, tokenSize-1 ) );
-      _token[std::min( _p - p0, tokenSize-1 )] = '\0';
+      memcpy( _token, p0, std::min( _p - p0, (long)tokenSize-1 ) );
+      _token[std::min( _p - p0, (long)tokenSize-1 )] = '\0';
    }
 
 public:
Index: Horde3D/Source/Horde3DEngine/egRenderer.cpp
===================================================================
--- Horde3D/Source/Horde3DEngine/egRenderer.cpp   (Revision 193)
+++ Horde3D/Source/Horde3DEngine/egRenderer.cpp   (Arbeitskopie)
@@ -20,6 +20,7 @@
 #include "egTexture.h"
 #include "egShader.h"
 #include "egLight.h"
+#include <stdint.h>
 
 #include "utDebug.h"
 
Index: Horde3D/Samples/Knight/main.cpp
===================================================================
--- Horde3D/Samples/Knight/main.cpp   (Revision 193)
+++ Horde3D/Samples/Knight/main.cpp   (Arbeitskopie)
@@ -19,6 +19,7 @@
 #include <iostream>
 #include <cstdlib>
 #include <cstring>
+#include <cstdio>
 #include "glfw.h"
 #include "app.h"
 
Index: Horde3D/Samples/Chicago/main.cpp
===================================================================
--- Horde3D/Samples/Chicago/main.cpp   (Revision 193)
+++ Horde3D/Samples/Chicago/main.cpp   (Arbeitskopie)
@@ -19,6 +19,7 @@
 #include <iostream>
 #include <cstdlib>
 #include <cstring>
+#include <cstdio>
 #include "glfw.h"
 #include "app.h"
 



Edit: Stupid phpBB removes spaces in front of lines even in code blocks. This probably breaks the patch, so I attached it manually again.

Attachments:
File comment: Patch to fix compilation under x64 ubuntu karmic.
fix_compilation.patch [2.06 KiB]
Downloaded 1043 times
Author:  mihai [ 04.10.2009, 03:31 ]
Post subject:  Re: Compiling on 64-bit Linux
Thanks for the patch!
Author:  mihai [ 04.10.2009, 14:11 ]
Post subject:  Re: Compiling on 64-bit Linux
The patch did not work for me, and it also has something that I can't find in my sources: Extensions/Terrain/Sample/main.cpp.

I attach the patch I used to build my Arch package. It should be used from above the source dir (Horde3D_SDK_1.0.0_Beta4/) with
Code:
patch -Np0 -i fix.patch
Maybe this would help someone else who like me, has a hard time using its command-line options.

Attachments:
fix.patch [2.23 KiB]
Downloaded 1020 times
Author:  phoenix64 [ 04.10.2009, 17:18 ]
Post subject:  Re: Compiling on 64-bit Linux
My patch is for the current sf.net SVN (with terrain extension).
Author:  Volker [ 03.11.2009, 11:15 ]
Post subject:  Re: Compiling on 64-bit Linux
Seems like this patch hasn't been integrated yet, so I did it now. But I wonder why you had to add #include <stdint.h> to egRenderer.cpp. I just compiled it under Ubuntu 9.10 and didn't need that. And VS2005 does not provide a stdint.h
Page 1 of 1 All times are UTC + 1 hour
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/