Author Topic: Orbiter on debian unstable (Read 32088 times)

archived · « **on:** June 13, 2006, 12:31:05 am »

Hi,

Has anyone built the orbiter on debian unstable? I'm having problems with the final linking. I'm using an svn checkout from the 10th and I've tried both g++-3.3.6 and g++-4.0.3 with the same results. Upon linking of the orbiter I get a mess of these errors:

`.L8111' referenced in section `.rodata' of Linux/OSDScreenHandler.o: defined in discarded section `.gnu.linkonce.t._ZN3DCE17ScreenHandlerBase25ReceivedGotoScreenMessageEiPNS_7MessageE' of Linux/OSDScreenHandler.o

other than that the compile is uneventfull. Even less so with g++4 as it gave out even fewer warning messages. I am just looking to see if anyone has tried this or has an idea of how to start trouble shooting it. I know pluto is built on debian stable and my pluto core is the only machine I run stable on, with all others in my house running unstable (no windows here). I'd like to run an orbiter on my laptop. I've tried the web orbiter and it works ok, but the refresh rate of the site get anoying after a while.

Thanks for any help,
Jason

archived · « **Reply #1 on:** June 14, 2006, 12:35:09 pm »

I've compiled the Orbiter on Etch a week or two ago, but I don't remember what the result on linking was. I'll update my system to current Etch and let you know on the outcome. As for Sid, I don't know any one that could help me test building the Orbiter there, so I can't give you any insights. Sorry.

archived · « **Reply #2 on:** June 14, 2006, 12:38:42 pm »

It seems to be a linker error, something like "undefined reference". You might want to recompile libDCECommon (do a make in src/DCE) and libPlutoUtils( do a make in src/PlutoUtils). When try to link Orbiter again.

Best regards,
Chris M.

archived · « **Reply #3 on:** June 16, 2006, 03:02:04 pm »

I've since updated my system to the latest versions of everything and installed g++-3.4. I've also updated my pluto source from svn and am still getting the same errors. Each time I try something different, I do a make clean on all the dependent libraries and rebuild. As a side not, Is it common for the code in svn to not compile due to missing/unfinished functions? (I'm ok with this as that's my coding style

I'm just curious) I'll keep looking to get an idea of what kind of things cause these linking errors and post as I try things. If you guys come up with any ideas or solutions please pass them along. Once I get a stand alone orbiter working on sid, I'll try to get it working on openzaurus/opie.

Jason

archived · « **Reply #4 on:** June 16, 2006, 06:27:41 pm »

jspeckman,
I am most interested in your progress on getting Orbiter running on a zaurus. I am not currently running OZ/opie but I would be more than happy to help test etc. if you can get it compiled. I have been unsuccessful in compiling using the default sharp rom/pocketworkstation on a zaurus C3100. I've tried a cross-compile environment using DSL as well as trying to compile directly on the z in pocketworkstation. (my post is just below this one: http://plutohome.com/support/phpbb2/viewtopic.php?t=788)

Let me know if I could help in any way.

DoTheDog

archived · « **Reply #5 on:** July 20, 2006, 03:23:46 am »

Hi all,

Finally got the orbiter to build with g++ 4.0. My earlier linker error was due to me building with g++ 3 and linking against system libraries built with 4. I had to modify some of the orbiter header files to get it to build. The reults are: It kinda works. The orbiter starts, but says my core is too old ( 18 ) Looks like it wants newer ( 28 )?? I'm building out of trunk, so I'm not entirely supprised. I tried building out of the current release tree, but The errors are beyond my minimal c++ knowledge to fix it to build with g++ 4. Also the orbiter that almost works tends to seg fault on exit which also does not clean up sdl. If anyone out there has had better luck let me know, otherwise I'll either wait for my core to get updated to a newer version when it comes out or run the windows orbiter under vmware

Jason

archived · « **Reply #6 on:** July 20, 2006, 09:20:30 am »

The best solution is to wait for the release which will be public in few days. This way you'll have the latest core and plugins and Orbiter will work fine since the serialization schema is the same.

Best regards,
Chris M.

archived · « **Reply #7 on:** July 20, 2006, 05:43:32 pm »

jspeckman,
Did you build it in OE? If so any way I can get your recipe? I have been attempting it with no love.

Rob

archived · « **Reply #8 on:** July 20, 2006, 10:58:15 pm »

I have not yet tried to build for the zaurus, only my debian unstable machine. I've been following the thread on building for the zaurus and it does not look pretty. To be honest I've not tried to build anything with OE yet, so I'm waiting to verify that what I've managed to build on my machine at least does work before I attempt a different architecture with an old compiler.

Jason

archived · « **Reply #9 on:** July 21, 2006, 05:42:25 am »

jspeckman,
Got ya. But you are building using gcc-4 correct? I'm trying to build SerializeClass in OE and have gotten a wierd error. I've posted it here:
http://www.oesf.org/forums/index.php?showtopic=20534&st=15

Have you seen that one?

Rob

archived · « **Reply #10 on:** August 14, 2006, 03:10:22 pm »

Still no luck with 2.0.0.40

The Orbiter builds with fewer errors to be corrected for gcc-4 and now connects to the dcerouter. However the orbiter now dies when it should be rendering the screen. Perhapse it's an sdl problem? Anyone else have any luck?

Jason

archived · « **Reply #11 on:** August 14, 2006, 04:36:33 pm »

If it crashes, it should create a coredump in /home/coredumps/1. Use gdb and give me the backtrace or enable remote assistance and I'll take a look.

Best regards,
Cristian Miron

News:

Author Topic: Orbiter on debian unstable (Read 32088 times)