Other ways to support Sylphis3D...
Syndicate
Porting to Linux
Thu, 06/07/2007 - 22:08 — harkal
Ok this thread is a follow up to the "Translating to a CMake" thread. Now the CMake is ready and we need to iron out runtime porting problems. The related bug in the tracker is http://mantis.sylphis3d.com/view.php?id=5 .
Summing up Sylphis3D can now compile and run under linux! However even if the GUI comes up and works, it crashes if we try to load the test map.
Good job!
Hmmm...
Did you try compiling it under Windows? It could be that it's one of the changes I made that makes it crash and not something platform related. (Maybe those scary casts :-S)
The current version is ok...
The current version is ok... it compiles and runs without problems under windows. Hoever I reverted the "scary cast".. which were wrong. It you look at it closer you will see that its changing the value. The funny thing is that the (S32) static cast I originaly used compiled under linux just fine! What GCC are you using that was causing you trouble?
Yea, I just noticed you
Yea, I just noticed you removed them. Doesn't compile here any more.
I'm compiling this on gcc 4.1.2. I think that it might be related to me compiling it on a 64bit platform. Would you mind doing sizeofs of both the types so we can compare?
I think I've found it. dSpaceID is a pointer type, isn't it? If that is the case then our problem is the different pointer size on 64bit architectures.
Hm... this is probably it..
Hm... this is probably it.. you are compiling on 64bits.... first of all the S32, U32, etc types should be redefined depending on the platform. These are in hklib/include/platform/types.h . When we sort out that we should so after the what type dSpaceID is.. and make a good fix for that problem...
I reverted the changes since the cast was faulty anyway, and we have to have a tree that compiles and runs...
First of all I just want to
First of all I just want to say why I was trying to make those awful (awful apart from being plain wrong) casts so you people don't think I'm a complete moron :-P. It was just that I thought that it might have been GCC that was more picky than MSVC++, otherwise I would never have done have written anything like that.
I think I've identified the problem. I'm pretty sure dSpaceID is a pointer, and pointers are 64bit on x86_64, while 32bit on x86. int (that is to say S32) is still 32bit even on x86_64. Do you think we could use a long int in those places that have conversion issues on x86_64 (long int are still 32bit on x86, aren't they)?
Using an S64 (signed long
Using an S64 (signed long int) seems to be 32 bit on x86 and 64 bit on x86_64 here. Using S64 therefore makes sylphis compile on both architectures.
Do you see any reason not to use S64? as far as I can see it should make any difference on 32bit and make it compile on 64 bit. I had a shallow look at the code and I couldn't find anything that would break the code in 64 bit either.
Hmm... S64 should be 64bits
Hmm... S64 should be 64bits on both architectures... I actually used that naming convension to remove some of the 64-32 bit issues. Maybe create a pointer type?
I did a cross-compile of an
I did a cross-compile of an application that printed the sizeof of most of the types. signed long int was 4 on 32bit and 8 on 64 bit. Try it yourself so we can be sure.
Yes that is a fact! The S*
Yes that is a fact!
The S* defines are now only for 32bit platforms... the types.h will have to be changed for 64bits... I didn't do that since I haven't tested a 64bit platform. But all code uses the S* types so we know that we use.
I was going to do something like this:
#ifdef 64BITS
typedef signed long int S64;
#else
typedef signed long long int S64;
#endif
And since that time is now(!), I just commited a fix for this in the svn... can you check if everything is ok on 64bits? Since I did the patch out of memory...
I think that there are
I think that there are architecture independent types defined in the c standard library, I just can't remember where... Defining a pointer type sounds good to me, if you think it'll work.
What should it be called? SPI (Signed Pointer-sized Integer) :-P
Other developers
Do you think dayal3 and/or any of the other people who have showed interest in sylphis linux development earlier are interested in helping with this? Is there any way to contact them?
noteventime, I think I've
noteventime,
I think I've already said thanks a number of times, but it never hurts for another. So, thanks for all your continued work on porting! :D
Just yesterday I finished getting X/KDE compiled on my brand new LinuxFromScratch system, and the 50meg ATI drivers are downloading as I write this. (Dialup, oiffles.) As soon as that's done, I'll grab the patch and try compiling.
The system I'll be compiling on is a 32 bit Intel, using the latest stable Kernel release and GCC 4.0.3, for reference's sake.
As soon as I have any results, I shall let you know! :)
-=Derek
Really, it was no problem
Really, it was no problem at all. If I wasn't so damn lazy (and my school had some better planning) I could have done it in two days. :-)
Thanks for trying the linux version, the more people we have to test it the sooner we'll have a working version. It's also good (as you've already noted) to make sure it works on older GCC versions (I can't see why it wouldn't but it's better to make sure anyway).
Just wanted to pop in and
Just wanted to pop in and deny any speculation of death and such. ;) I ended up having great difficulties getting my ATI card working in my laptop under Linux, so I've just decided to test the Sylphis+Linux compile on my desktop once I get LinuxFromScratch installed on it.
Almost there --just about to compile Xorg...
-=Derek
What can I do to get it to compile?
I am running kubuntu 7.04 32bit and I just checked out the svn tree
I then proceeded to do a cmake . in the src/sylphis directory and got the following error.
CMake Error: cannot find source file /sylphis3d/sylphis/trunk/runtime/src/sylphis/core/src/python/sylphis_wrap.cpp" for target "sylphis"
I don't see this file anywhere and should either be put back in the tree or taken out of the CMakeLists.txt; am I right?
I am looking forward to testing this some more.
~Ryan
Linux~ the best things in life are free.
That file is autogenerated
That file is autogenerated by SWIG... you should have swig installed...
You'll need to generate the
You'll need to generate the SWiG file manually. A great contribution you could make would be to make the CMake autogenerate the file. There is a SWiG module included in CMake so it shouldn't be too hard. I'm busy with other things at the moment.
I think the file is generated by running "swig -python -c++ -o core/src/python/sylphis_wrap.cpp core/src/python/sylphis.i".
I finally got around to
I finally got around to testing out the Linux compile. Yay! Sorry about the delay; if you only knew how many distros I've been through in the last month. ;)
Generally, the compile went smoothly. I had a little trouble with the patched ODE at first, but that ended up working just fine. (Something about the patch was clashing the the ODE demos, so I had to edit the makefile to disable them.)
Compiling Sylphis itself also went smoothly up until that last step --or what I'm assuming to be the last step. I did a "cmake ." followed by a "ccmake ." to point to the /usr/local prefix for stackless, followed by a simple "make" :
[ 6%] Built target hk
[100%] Built target sylphis
Finally I tried a "make install" and got an error:
make: *** No rule to make target `install'. Stop.
What am I missing? :) I grabbed the latest (rev 20) from SVN, and have not applied the cmake patch from Mantis, considering patch told me it was already applied.
For reference, I'm on Fedora 7 using the stock GCC 4.1.2. Nvidia drivers.
Thanks!
-=Derek
Doh.
OIffen, I feel silly. Just looking through the makefiles and realized the presence of the "Release" folder. Duh.
Anyway, with that obviousness out of the way, I've run into another problem; after copying the contents of Release/ up to sylphis/trunk/runtime/, "./sylphis" spits out:
Traceback (most recent call last):
File "./base/core/entry.py", line 35, in
import sys, sylphis, sylphisextra
File "./system/sylphisextra.py", line 11, in
import mthread
File "./base/core/mthread.py", line 37, in
import stackless
ImportError: No module named stackless
Terminating python code : no available engine running
Exception : Failed to import entry code
Hmm, this is familiar from Windows, only I don't know how to fix it this time.
Any thoughts? Further details I can provide?
-=Derek
I am really guessing here,
I am really guessing here, but you probably don't have the development files for the "stackless" extentions for python installed.
Where and how to get them beats me, but you could have a look at this page:
http://www.stackless.com/
P.S.: Long time no update from Harkal, is he on vacation after finishing his military service? :)
http://freegamearts.myexp.de/
Thanks for the thought,
Thanks for the thought, however I've compiled all dependencies from source; I inherently have the development files.
I'm pretty sure my problem has its roots in Stackless being installed in /usr/local/stackless rather than /usr. I have tried installing to /usr, overwriting any other versions of Python in my system, but that didn't do anything other than forcing me to recompile standard Python. ;)
Considering both Noteventime and Harkal have compiled and run Sylphis on Linux, I'm hoping they have some insights.
-=Derek