The bad news. Currently it is semi-ignoring isolation mode. And actually, that is horrible news because it basically defeats the entire purpose.
Spring itself seems to be working correctly, but it's suffering from the missing font bug.
So basically, even tho the datadir correctly gets set, springlobby is still writing files in ~ (home) instead of ./ (current directory).
Here is the trick tho... DO NOT RUN THIS ON A MACHINE THAT YOU HAVE SPRING INSTALLED ON ALREADY! IT WILL APPEAR TO WORK JUST FINE, BUT IN ACTUALLITY IT IS USING YOUR ALREADY SET UP DATADIRS IN ~ !
Now, once you have uninstalled spring from your machine, you need to delete ~/.spring and ~/.springrc , then head over to filesystem/etc/games and delete "spring". This should clear your system of spring stuff.
I have included shell scripts that will put spring in isolation mode for each program (spring/settings/lobby). They are located in <archive root>/cde-root/usr/games .
The shell scripts look like this:
Code:
#!/bin/sh
export SPRING_ISOLATED=1 ./springlobby
However, springlobby when run even in isolation mode will still write files (specifically .springrc and .springlobby in ~) in ~. This is not good. Moreover, it will also not be able to find any games you have (even if you put them in games/maps folders inside <archive root>/cde-root/usr/games (this is the location listed in infolog as the working datadir). Also, don't forget the fonts issue.
Again, in order to properly test and debug this: SPRING AND ALL RELATED CONFIG FILES MUST BE PURGED FIRST!
END USERS SHOULD NOT ATTEMPT TO USE THIS! IT DOESN'T WORK RIGHT YET!
Any help would be GREATLY appreciated. Once we get this all sorted, i plan to provide a *nix spring portable option, instead of just having the windows portable. It takes all of a few seconds to build, and I need to build one for myself upon every engine version change, so it makes sense to provide portable for linux users as well. This will also make your game capable for use in Desura Linux.
Last edited by Forboding Angel on 02 Dec 2011, 03:03, edited 1 time in total.
Will take a closer look over the next 2 days, but here's some pointers right away: - SL knows nothing of engine's isolation mode, it needs to be in its own portable setting, which obv. isn't being triggered - the whole dir mess is why I hinted at doing this in a chroot - shell wrappers should forward args, ie call "binary ${@}"
Joined: 17 Nov 2005, 02:43 Location: Raegquitting Spring on 04/24/12
koshi wrote:
- SL knows nothing of engine's isolation mode, it needs to be in its own portable setting, which obv. isn't being triggered
I'm pretty sure it is, because it doesn't write anything outside of it's install dir. I put springlobby.conf and springsettings.cfg in it's working datadir. Afaik that is supposed to trigger portable, and indeed, when I did that is when SL started graying out the spring tab on the preferences menu.
koshi wrote:
- the whole dir mess is why I hinted at doing this in a chroot
I don't know what that means.
koshi wrote:
- shell wrappers should forward args, ie call "binary ${@}"
I understand what this means, but I dunno how it's related.
zwzsg wrote:
Granted I don't know much about Linux, but are you sure it's normal to ship you archive with \home\forboding\ ?
Without going into a long discussion about how cde works, just suffice it to say that that is how cde does it. In a way it recreates the folder structure on your machine. Don't worry, nothing in there is actually from my ~.
tar xifz spring-portable.tar.gz tar: cde-root/usr/lib64: Cannot create symlink to `lib': File exists tar: cde-root/lib64: Cannot create symlink to `.//lib': File exists tar: Exiting with failure status due to previous errors
second: cde-root/usr/games$ ./spring ./spring: error while loading shared libraries: libboost_regex.so.1.42.0: cannot open shared object file: No such file or directory
Joined: 17 Nov 2005, 02:43 Location: Raegquitting Spring on 04/24/12
Yeah well, koshi and I (mainly koshi) figured out today that this method won't work.
So unless you guys decide to statically link and make, this is a non-starter.
I don't understand why you guys aren't providing a portable for linux anyway. Just do it for ubuntu/debian. Portable doesn't need to support every distro under the sun.
I don't understand why you guys aren't providing a portable for linux anyway. Just do it for ubuntu/debian. Portable doesn't need to support every distro under the sun.
Joined: 17 Nov 2005, 02:43 Location: Raegquitting Spring on 04/24/12
Well, I don't know how, and setting up a vm to try to compile spring for someone who has never compiled anyhtign on linux before is kind of a not great idea. However, if someone would make the portable with static stuff, from what I understand all that needs to be swapped out is the binaries on every new spring version, which means replacing all of 3 files.
"export LD_LIBRARY_PATH=../../usr/lib/" to spring.sh helps a bit, but sound still doesn't work...
i'm unsure how to correctly create a portable spring executable for different linux distributions.i think openal + opengl has to be dynamicly loaded, the rest can be staticly linked.
Quote:
which means replacing all of 3 files.
no, you forgot for example the ais or updated content files, or... also that would be the easy part...
Joined: 17 Nov 2005, 02:43 Location: Raegquitting Spring on 04/24/12
Well unfortunately this has grown larger than I am capable of managing. To say I'm disappointed is the understatement of the year.
If any of you guys would be willing to maintain one, I think my gratitude probably goes without saying, but suffice it to say that it would be a huge burden off of me. I am being inundated with requests for evo on desura linux (have been for several months, but I think most people were expecting 1.9 to be a release for it, and after that release, the floodgates opened), and it really sucks to only be able to shrug and offer up "I'm working on it".
I've looked into the cde stuff a little more today with the conclusion that Imo it's too finicky to build and maintain. That makes a statically linked build of spring probably the best option. I've started (on a 32bit buntu 10.04) by setting
Code:
SET(CMAKE_FIND_LIBRARY_SUFFIXES ".a" )
in spring's top cmake file which brings one surprisingly far. Abma was incidentally spot on with his guesses about openAl and gl. Both aren't available as static libs on the box. A static build of Al was pretty easy. However I'm pretty sure I shouldn't link a static build of mesa's libGL into the spring binary... If anyone has some pointers please let's hear them. Otherwise I might have more to report later today.
aren't the OpenGL and OpenAL APIs designed in a way that makes them pretty robust to changes of any kind, so that you only need to use the correct 32/64 bitness basically? saying... maybe it makes to still use the shared version of these libs, and it would work fine.
Setting the library find suffix is a pretty blunt weapon. Atm I cannot tell cmake to look for shared libs for AL and ogl, but static for the rest. I've fooled configure to proceed by symlinking the gl lib even Re: using shared libs for them making sense, for ogl that's even mandatory unless everyone using this build wants to play with software render, right?
there is a way to set per-target file suffix. we once used that (or still do?) to switch between the default chosen for libs on OS X (.dylib to .so, for AIs).
... yes we do, in the FixLibName macro in rts/build/cmake/Util.cmake
"Target" means that's controlling the suffix of sth that cmake is generating, so not useful to me. Basically I'd need to be able to switch the suffix for the AL/GL Find* commands only. Haven't tried if toggling it before/after the Find* is functional yet.
Found a way to have .so suffix for openAL/GL and .a for the rest: https://github.com/renemilk/spring/comm ... 0a217ec0d6 Unsurprisingly this results in a gazillion link errors (see attachment). I'm open for suggestions as to what I'm doing wrong.
hmmm strange. it fails to link to libIL.a for example, cause it misses png and TIFF symbols. i guess this means, some setting is wrong, and not that some libs are missing. is -fPIC needed? reading about it, it seems to be needed when compiling shared libs.
Joined: 01 Jun 2005, 10:36 Location: The Netherlands
AFAIK the whole transitive closure of the static dependencies need to be specified.
So if DevIL depens on libpng, libmng, libtiff and libjpeg, then the static libraries for those needs to be specified on the linker command line too. And if e.g. libpng depends on libz, then libz needs to be specified on the linker command line too, etc.
Users browsing this forum: No registered users and 0 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
Home
Download
Login
Register
FAQ
Search
