Skip to main content ↑ ↓
Topic: Sphere 1.5, 1.6 beta (Read 563168 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Sphere 1.5, 1.6 beta

Reply #30 –
Doesn't SDL normally use `sdl-config --libs` or something to generate the necessary parameters? Find which SConscript files are calling that then go from there?

Re: Sphere 1.5, 1.6 beta

Reply #31 –
Yes, you can use SDL-Config, and Sphere does. It doesn't work nearly as well as it is claimed to.

What is the output of `sdl-config --libs`? This looks like a linking issue.

...It is possible that the SDL in Ubuntu repos is compiled without joystick and timer support, but that would be strange.

Re: Sphere 1.5, 1.6 beta

Reply #32 –
-L/usr/lib/i386-linux-gnu -lSDL

I also can't imagine joystick support not being there. I remember a few years ago at least I could use the joystick in pygame, which is based on SDL... But that's a pretty distant link to this. :P

Re: Sphere 1.5, 1.6 beta

Reply #34 –
-I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT

Edit: I also have SDL2 installed. Could it be confusing them somehow?

Re: Sphere 1.5, 1.6 beta

Reply #35 –
That also looks good.

SDL2 shouldn't conflict. All the SDL2 headers should be in /usr/include/SDL2, and the libraries should be called SDL2 and SDL2_[libname].

When I compiled Sphere on Linux (I did it again, just to check), I had both SDL and SDL2, as well as a separate SDL2 install in /usr/local (which is given preference on my system), which has no audio or power management compiled in. I'll see what I can find about this. I would really like to think it is the SDL included in the Ubuntu repos based on what we are seeing. But that also sounds strange, since these are very commonly used features in SDL, and it would be very surprising if these weren't a part of Ubuntu's SDL.

EDIT: What version of SDL do you have? I am specifically compiling against SDL 1.2.15, but it very likely will work against any SDL version 1.2.

Re: Sphere 1.5, 1.6 beta

Reply #36 –
Standard Ubuntu version: package libsdl1.2debian and libsdl1.2-dev, version 1.2.15ubuntu2. Man, I wonder what's going on here.

Re: Sphere 1.5, 1.6 beta

Reply #37 –
I've pushed all the changes that I need for Sphere to compile on my system to my github fork.

Perhaps if you clone from it, specifically here, with the changes that work for me, and try compiling that?

EDIT: Question for someone who is more knowledgeable about the wiki: What page should I add the steps for compiling Sphere on Linux? I was looking at the Getting Started, Linux section, but I seem to recall the old wiki having instructions for compiling in the past.

Re: Sphere 1.5, 1.6 beta

Reply #38 –
Was already getting Sphere from there, so I just undid my local changes and did a git pull. That didn't work; got the same output. So then I did a clean checkout. Still gives the same error.


Quote
EDIT: Question for someone who is more knowledgeable about the wiki: What page should I add the steps for compiling Sphere on Linux? I was looking at the Getting Started, Linux section, but I seem to recall the old wiki having instructions for compiling in the past.

If memory serves properly, there was an article called "Compiling Sphere" which had a Linux section on it.
I'm also hoping to have a full script soon to pull in your version of Sphere, all of its dependencies, and compile it all. But I need to get it compiling here first...
 

Re: Sphere 1.5, 1.6 beta

Reply #39 –
I pushed some more changes (mostly the ones we just worked out) to it before my last post.
OK, let's just test to see that the SDL libraries for Ubuntu have the functions that are apparently missing.

To find where the libraries are:
Code: [Select]

ls /usr/lib | grep -i libsdl


Or at least it is /usr/lib on my machine. It might be different on Ubuntu.

If there are multiple results (usually with different numbers on the end of .so), run `file` on them to see where they point (many will be symlinks). Once you get an actual executable, see what the output of this is:

Code: [Select]

nm -D /usr/lib/[what the above command produced] | grep SDL_NumJoysticks


The output should be an address, a letter, and then SDL_NumJoysticks. The letter should also not be 'U'.

EDIT: Interesetingly, from a little snooping it seems that Ubuntu gets a man page for sdl-config (Arch doesn't!). Maybe that has some info on linking.

Re: Sphere 1.5, 1.6 beta

Reply #40 –
Your first command outputs nothing!
Okay, turns out it's in /usr/lib/i386-linux-gnu/.
libSDL-1.2.so.0.11.4 is a valid file there.
Your final command prints out this:
Code: [Select]
00032900 T SDL_NumJoysticks

Re: Sphere 1.5, 1.6 beta

Reply #41 –
Makes sense, the sdl-config --libs includes that path. And that is exactly the same as what I get (in fact, I get the exact same actual executable, and the same address and symbol type).

Ubuntu also distributes static libraries for SDL 1.2. We can check to see if linking is being done against that (again, shouldn't really make a difference, but that's not how it's working on my system).

You can try changing the SConscript file in sphere/source/unix to this:

Code: (python) [Select]

Import('base_env COMPILER')

env = base_env.Clone()
COMPILER.SetupSDL(env)

#this is what we want.
env.SharedLibrary('unix', Split("""
    unix_audio.cpp
    unix_filesystem.cpp
    unix_input.cpp
    unix_network.cpp
    unix_screenshot.cpp
    unix_system.cpp
    unix_sphere_config.cpp
    unix_time.cpp
    unix_video.cpp
    unix_main.cpp
    """))

#this keeps the build working, but the engine executable will be non-functional.
env.Library('unix', Split("""
    unix_audio.cpp
    unix_filesystem.cpp
    unix_input.cpp
    unix_network.cpp
    unix_screenshot.cpp
    unix_system.cpp
    unix_sphere_config.cpp
    unix_time.cpp
    unix_video.cpp
    unix_main.cpp
    """))


Then, run `ldd libunix.so` in the same directory. It should show libSDL-1.2.so (possibly with a number appended) as one of the linked libraries if you are linking to the shared library.

You will have to manually delete libunix.so afterwards for the build to produce a functional engine executable.

It really should work anyway, but if you are not getting linked to the shared library then things aren't working the same way as on my machine.

Re: Sphere 1.5, 1.6 beta

Reply #42 –
Quote
Then, run `ldd libunix.so` in the same directory.

I suppose I need to do this after I have successfully run Scons? Building still fails, but at least it fails at a different point now:

Code: [Select]
scons: Reading SConscript files ...
os.name: posix
Using compiler: linux
Found sdl-config: /usr/bin/sdl-config
Using subsystem: unix
Found sdl-config: /usr/bin/sdl-config
Found wx-config: /usr/bin/wx-config
Found sdl-config: /usr/bin/sdl-config
Found sdl-config: /usr/bin/sdl-config
scons: done reading SConscript files.
scons: Building targets ...
g++ -o source/engine/engine source/engine/SpritesetServer.o source/engine/benchmark.o source/engine/engine.o source/engine/log.o source/engine/map_engine.o source/engine/render.o source/engine/rendersort.o source/engine/parameters.o source/engine/script.o source/engine/sfont.o source/engine/sfxr.o source/engine/simage.o source/engine/smap.o source/engine/sphere.o source/engine/ssfxr.o source/engine/sspriteset.o source/engine/swindowstyle.o source/engine/PlayerConfig.o -Lsource/common -Lsource/particle_engine -L/usr/lib/i386-linux-gnu -Lsource/engine/unix -lcommon -laudiere -lcorona -lmng -ljpeg -lz -lparticle_engine -lSDL -lunix -ldl -ljs
g++ -o source/video_unix/sdl32/libsdl32.so -shared source/video_unix/sdl32/sdl32.os source/video_unix/sdl32/configfile.os source/video_unix/sdl32/defaultfile.os source/video_unix/sdl32/defaultfilesystem.os -lz
g++ -o source/util/spktest/spktest source/util/spktest/spktest.o -Lsource/common -lz -lcommon -lcorona
Install file: "source/util/tst2rts/tst2rts" as "build/linux/util/tst2rts"
g++ -o source/util/vmap2rmp/vmap2rmp source/util/vmap2rmp/vmap2rmp.o -Lsource/common -lz -lcommon -lcorona
Install file: "source/util/vsp2rts/vsp2rts" as "build/linux/util/vsp2rts"
Install file: "source/video_unix/sdl32/libsdl32.so" as "build/linux/system/video/sdl32.so"
source/common/libcommon.a(PackageFile.o): In function `CPackageFile::Close()':
PackageFile.cpp:(.text+0x38): undefined reference to `inflateEnd'
source/common/libcommon.a(PackageFile.o): In function `CPackageFile::Read(void*, int)':
PackageFile.cpp:(.text+0x165): undefined reference to `inflate'
source/common/libcommon.a(PackageFile.o): In function `CPackageFile::Seek(int)':
PackageFile.cpp:(.text+0x395): undefined reference to `inflateEnd'
PackageFile.cpp:(.text+0x3d8): undefined reference to `inflateInit_'
source/common/libcommon.a(PackageFile.o): In function `CPackageFile::CPackageFile(_IO_FILE*, int, int, int)':
PackageFile.cpp:(.text+0x517): undefined reference to `inflateInit_'
collect2: error: ld returned 1 exit status
scons: *** [source/util/spktest/spktest] Error 1
scons: building terminated because of errors.


The internet tells me this, but trying to add env.Append(LINKFLAGS = ' -lz ') makes zero difference in the output.

I also just tried to compile something entirely unrelated (OpenMW) to see if my build system didn't somehow break, but that compiles just fine.

Re: Sphere 1.5, 1.6 beta

Reply #43 –
I used both env.Prepend(LINKFLAGS ' -lz ')  and env.Append(LINKFLAGS ' -lz '). You will probably need to put that in the top level SConstruct file, right after
Code: [Select]


# common options
base_env.Append(CXXFLAGS = ['-DUNIX'])
#new
base_env.Prepend(LINKFLAGS ' -lz ')
base_env.Append(LINKFLAGS ' -lz ')


I thought that made it into the git repo. Actually makes me wonder why it's working for me now when I definitely had to do that before.

If there is a libunix.so in the unix folder, you can run ldd on it at any point. Shared libraries need to be all linked up (not necessarily have all their symbols defined, though), while static libraries are just archives of object files. We need a shared library of libunix so we can see how it got linked to SDL.

If everything compiles and links fine with a shared library of libunix, there is a slightly inelegant way of making it all work, though--as in, having fully functional Sphere native on Linux. If it comes to it, it may at least be worth doing to see if that's the only problem left.

Re: Sphere 1.5, 1.6 beta

Reply #44 –
Adding that results in
Code: [Select]
scons: Reading SConscript files ...
  File "/home/vincent/src/sphere/sphere/SConstruct", line 134

    base_env.Prepend(LINKFLAGS  ' -lz ')

                                      ^

SyntaxError: invalid syntax


Changing the lines to
Code: [Select]
base_env.Prepend(LINKFLAGS = ' -lz ')
base_env.Append(LINKFLAGS = ' -lz ')

but I don't know if that's the right thing to do or not. In any case, it resulted in this:

Code: [Select]
scons: Reading SConscript files ...
os.name: posix
Using compiler: linux
Found sdl-config: /usr/bin/sdl-config
Using subsystem: unix
Found sdl-config: /usr/bin/sdl-config
Found wx-config: /usr/bin/wx-config
Found sdl-config: /usr/bin/sdl-config
Found sdl-config: /usr/bin/sdl-config
scons: done reading SConscript files.
scons: Building targets ...
g++ -o source/util/spktest/spktest -lz -lz source/util/spktest/spktest.o -Lsource/common -lz -lcommon -lcorona
source/common/libcommon.a(PackageFile.o): In function `CPackageFile::Close()':
PackageFile.cpp:(.text+0x38): undefined reference to `inflateEnd'
source/common/libcommon.a(PackageFile.o): In function `CPackageFile::Read(void*, int)':
PackageFile.cpp:(.text+0x165): undefined reference to `inflate'
source/common/libcommon.a(PackageFile.o): In function `CPackageFile::Seek(int)':
PackageFile.cpp:(.text+0x395): undefined reference to `inflateEnd'
PackageFile.cpp:(.text+0x3d8): undefined reference to `inflateInit_'
source/common/libcommon.a(PackageFile.o): In function `CPackageFile::CPackageFile(_IO_FILE*, int, int, int)':
PackageFile.cpp:(.text+0x517): undefined reference to `inflateInit_'
collect2: error: ld returned 1 exit status
scons: *** [source/util/spktest/spktest] Error 1
scons: building terminated because of errors.

It seems to error less than before, but maybe it didn't make a difference since it's stumbling on the same issue.