Raydium 3D Game Engine

Official forum for everything about Raydium, ManiaDrive, MeMak, ...
It is currently Thu Mar 28, 2024 10:52 am

All times are UTC




Post new topic Reply to topic  [ 40 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Wed May 06, 2009 2:15 pm 
Offline

Joined: Wed May 06, 2009 2:06 pm
Posts: 30
I got compiled raydium svn revision 838 on Ubuntu 9.04 (amd64) with some tweaks:
There are error "relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC"

1)
Added to Makefile:15
COMPILE_OPTIONS= -g -D LIBRAY -fPIC

2)
Added to configure:221
--disable-simplexml --disable-xmlreader --disable-xmlwriter --enable-soap --with-pic\

This last might be fault of php.
I do not know anything about pic, but I found this when searching with error message:
http://www.gentoo.org/proj/en/base/amd6 ... t=1&chap=3

3) Error on making:
Creating: raydium/compile/myglut.o
In file included from /usr/include/X11/extensions/dpms.h:50,
from raydium/myglut-x11.c:25,
from raydium/myglut.c:35:
/usr/include/X11/Xmd.h:135: error: conflicting types for 'INT32'
/usr/include/jmorecfg.h:161: error: previous declaration of 'INT32' was here
make: *** [raydium/compile/myglut.o] Error 1


I figered there are in /usr/include/jmorecfg.h:160
#ifndef XMD_H /* X11/xmd.h correctly defines INT32 */
So I think Xmd.h and jmorecfg are loaded wrong order. I got it compiled when I put
raydium/common.h:20 #include <X11/Xmd.h>
This proofs my claim, but its not right solution.

Then I got mania_drive.c compiled and running.


Top
 Profile  
 
PostPosted: Wed May 06, 2009 5:11 pm 
Offline

Joined: Wed May 06, 2009 2:06 pm
Posts: 30
Edited: added ftp-links for pathces.

I made script to handle this.
Code:
wget http://ftp.cqfd-corp.org/patch838_amd64_for_common_h.txt
wget http://ftp.cqfd-corp.org/patch838_amd64_for_configure.diff
wget http://ftp.cqfd-corp.org/patch838_amd64_for_make.diff
svn checkout svn://raydium.org/raydium/trunk
patch -p0 < patch838_amd64_for_make.diff
patch -p0 < patch838_amd64_for_configure.diff
patch -p0 < patch838_amd64_for_common_h.diff

cd trunk
./configure
make

#./odyncomp.sh mania_drive.c


Last edited by aapo on Fri May 08, 2009 7:40 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Fri May 08, 2009 6:12 am 
Offline

Joined: Tue Jul 08, 2008 2:37 am
Posts: 181
Hi aapo and welcome to the Raydium forum.

Great news! Sadly I haven't set up a 64-bit based GNU/Linux environment ATM to test you changes, but I'll try to do this and consequently commit them ASAP. Feel free to upload the files to the CQFD Corp. anonymous FTP Server.

Thank you very much.

Best regards,
st


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

Top
 Profile  
 
PostPosted: Fri May 08, 2009 7:56 am 
Offline

Joined: Wed May 06, 2009 2:06 pm
Posts: 30
Patching configure might be same issue than in (last two posts):
viewtopic.php?f=7&t=575

(it is about compiling libphp. Is this bug in libphp, or is Raydiums configure misconfigured? I know very little about libphp.)


Without patching makefile, I got same linking error message "/usr/bin/ld: raydium/compile/background.o: R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC"
This is obviously related to 64-bit, but I do not know is there some one-size-fit-all solution.

Pathcing common.h (changing order of loaded system-libraries) is related to X11, so I don't understand how you can compile it for X11.


Top
 Profile  
 
PostPosted: Wed May 20, 2009 11:08 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
Not sure to fully understand the PHP trouble, but about the two others points, there a few things to think about :

1 - The fPIC setting should be added ONLY for amd64, and not for x86 targets, where no native "offset memory referencing" feature is available and GCC then generates some insanely complicated code. So the ./configure script should detect amd64 and then enable the "fpic-thing".

2 - The conflict you discovered on your system between X11 includes and libjpegs includes is ... quite tricky ! Raydium includes libjpeg first, and way later in the compilation, X11, during "myglut" building. We must find a smart way to resolv this without breaking anything else, and for any other target (win32, macosx, ...)


Top
 Profile  
 
PostPosted: Fri Aug 14, 2009 12:48 pm 
Offline
User avatar

Joined: Thu Sep 29, 2005 2:59 pm
Posts: 828
For linux, this script could returns 1 if the cpu is an AMD64
CHECK64=`cat /proc/cpuinfo|grep flags|grep lm|wc -l`
CHECKAMD=`cat /proc/cpuinfo|grep AuthenticAMD|wc -l`
CHECKAMD64=`if [ "$CHECK64" -gt "0" ] && [ "$CHECKAMD" -gt 0 ];then echo 1; fi`
echo $CHECKAMD64


Top
 Profile  
 
PostPosted: Fri Aug 14, 2009 1:50 pm 
Offline

Joined: Wed May 06, 2009 2:06 pm
Posts: 30
Do not work on my Lenovo t500 ubuntu 9.04_amd64

Whole cpuinfo:
Code:
cat /proc/cpuinfo                                 
processor       : 0                                                           
vendor_id       : GenuineIntel                                                 
cpu family      : 6                                                           
model           : 23                                                           
model name      : Intel(R) Core(TM)2 Duo CPU     P8600  @ 2.40GHz             
stepping        : 10                                                           
cpu MHz         : 800.000                                                     
cache size      : 3072 KB                                                     
physical id     : 0                                                           
siblings        : 2                                                           
core id         : 0                                                           
cpu cores       : 2                                                           
apicid          : 0                                                           
initial apicid  : 0                                                           
fpu             : yes                                                         
fpu_exception   : yes                                                         
cpuid level     : 13                                                           
wp              : yes                                                         
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm ida tpr_shadow vnmi flexpriority
bogomips        : 4787.80
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Duo CPU     P8600  @ 2.40GHz
stepping        : 10
cpu MHz         : 800.000
cache size      : 3072 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm ida tpr_shadow vnmi flexpriority
bogomips        : 4789.46
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:


How about
Code:
uname -r
Linux leno 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 01:19:55 UTC 2009 x86_64 GNU/Linux


Or simpler
Code:
uname -m
x86_64


Top
 Profile  
 
PostPosted: Sat Aug 15, 2009 8:47 am 
Offline
User avatar

Joined: Thu Sep 29, 2005 2:59 pm
Posts: 828
Hmm, maybe I explain myself wrong.
The script is for detecting AMD 64 cpus, not or detecting AMD64 system (that can be used with AMD or Intel cpus). In other words your CPU is INTEL, not AMD.
Anyway, when you built raydium, did you have problems?


Top
 Profile  
 
PostPosted: Sun Aug 16, 2009 5:30 am 
Offline

Joined: Wed May 06, 2009 2:06 pm
Posts: 30
Yes, I have problems with compiling raydium, but I have solution for it.

I can't compile vanilla version on svn. I must use these patches before configure and make.
Code:
wget http://ftp.cqfd-corp.org/patch838_amd64_for_common_h.txt
wget http://ftp.cqfd-corp.org/patch838_amd64_for_configure.diff
wget http://ftp.cqfd-corp.org/patch838_amd64_for_make.diff

svn checkout svn://raydium.org/raydium/trunk
#Checked out revision 864.
patch -p0 < patch838_amd64_for_make.diff
patch -p0 < patch838_amd64_for_configure.diff
patch -p0 < patch838_amd64_for_common_h.txt

cd trunk
./configure
make


Without any patch, configure passes, but make give this error:
Code:
Creating: raydium/compile/myglut.o
In file included from /usr/include/X11/extensions/dpms.h:50,
                 from raydium/myglut-x11.c:25,
                 from raydium/myglut.c:35:
/usr/include/X11/Xmd.h:135: error: conflicting types for 'INT32'
/usr/include/jmorecfg.h:161: error: previous declaration of 'INT32' was here
make: *** [raydium/compile/myglut.o] Error 1


If I modify common.h, make will compile everything but linking give this error:
Code:
/usr/bin/ld: raydium/compile/background.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
raydium/compile/background.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [libraydium.so.0.0] Error 1


I might use word 'amd' wrongly. I mean 64bit system.

Patching configure and make is needed because of that -fPIC, but I do not know why system libraries are loaded in wrong order and what is right way to solve it.


Top
 Profile  
 
PostPosted: Sun Aug 16, 2009 6:54 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
We start to have a lot of issues with 64 bits systems, we should try to solve this once and for all. I'm still using a 32 bits Linux distribution on my main system, so I can't maintain this target, but I'll try to find such a system.

Note the INT32 trouble is distro related, not specific to Raydium (even if there's probably a way to fix this in Raydium itself [using a #undef, perhaps ?]).


Top
 Profile  
 
PostPosted: Tue Aug 18, 2009 8:55 am 
Offline
User avatar

Joined: Thu Sep 29, 2005 2:59 pm
Posts: 828
Xfennec, no need to worry about. I'll try to do a fix for this and then a commit.
Briefly:
-AMD64 cpus will have special parameters for compiling (make and configure), that's not a problem. The previous script will detect AMD64 cpus.
-We have to change the order of the includes. Only in AMD64? Currently it's working fine with all tested applications, but maybe that change could becomes into future problems.
I'll prepare a (single) patch and i'll post here before commit, for critics.

By the way before each problematic include I tried #undef's already, without luck.


Top
 Profile  
 
PostPosted: Tue Aug 18, 2009 9:55 am 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
Fine, OK !

About the INT32 trouble, reversing some includes is enough to fix it ? If so, we can do this for all platforms, not only for 64, since it's always good to get rid of a ifdef/endif pair.


Top
 Profile  
 
PostPosted: Tue Aug 18, 2009 10:37 am 
Offline
User avatar

Joined: Thu Sep 29, 2005 2:59 pm
Posts: 828
Ok, I can try to inverse the order for all platforms.

Apart,this "workaround" is linux specific (I use cat, /proc/cpu...) Are windows/mac users having also this problem?


Top
 Profile  
 
PostPosted: Tue Aug 18, 2009 11:29 am 
Offline
User avatar

Joined: Thu Sep 29, 2005 2:59 pm
Posts: 828
Well, first try.
This works on AMD64 with a raydium svn new checkout, but I can not test on linux32.
Volunteers?
patch: http://www.sendspace.com/file/exwbzf


Top
 Profile  
 
PostPosted: Tue Aug 18, 2009 11:39 am 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
configure is used only on "shell compliant" targets, ie Linux and MacOS X (and probably FreeBSD, one day). I have no idea of 64 bits support is done with MacOS X.

But using /proc is not a good idea, since it's Linux specific. Isn't "uname" a better option ? Is "getconf LONG_BIT" available with MacOS X ?

Note : started writing this post before your last one :)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 40 posts ]  Go to page 1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 36 guests


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

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group