Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Cross-Platform Development => Topic started by: kasperl on July 14, 2010, 07:41:41 am
-
After being gone for years, I've decided to give FSO another go. I'm still running the same hardware as 5 years ago, but I've changed to Debian, and I'm currently trying to compile from SVN. Since my wiki account got disappeared, things I'd like to edit but can't:
- libsdl12-dev is available as libsdl1.2-dev on Debian. Haven't a clue about the Ubuntu name so it might not be a typo, but it'll confuse the newbies mightily and autogen doesn't exactly respond all that eloquently.
- The wiki gives some script to check out a SVN dir with CVS. Might work, haven't tried or looked, but it doesn't look all that great compared to "svn co" and "svn update".
And a more interesting (and show-stopping issue):
- Running make gives the following output:
Making all in code
make[1]: Entering directory `/home/kasperl/freespace/fs2_open/code'
g++ -DPACKAGE_NAME=\"fs2_open\" -DPACKAGE_TARNAME=\"fs2_open\" -DPACKAGE_VERSION=\"3.6.13\" -DPACKAGE_STRING=\"fs2_open\ 3.6.13\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DNO_CD_CHECK=1 -DNDEBUG=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSCP_UNIX=1 -DNO_DIRECT3D=1 -I. -m64 -march=athlon64 -ansi -DLUA_USE_LINUX -g -Os -Wall -funroll-loops -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/libpng12 -I/usr/include/lua5.1 -fsigned-char -Wno-unknown-pragmas -Wno-deprecated -Wno-char-subscripts -MT ai.o -MD -MP -MF .deps/ai.Tpo -c -o ai.o `test -f 'ai/ai.cpp' || echo './'`ai/ai.cpp
In file included from /usr/include/features.h:354,
from /usr/include/stdio.h:28,
from ./globalincs/pstypes.h:35,
from ./ai/ai.h:15,
from ai/ai.cpp:14:
/usr/include/gnu/stubs.h:9:27: error: gnu/stubs-64.h: No such file or directory
In file included from ai/ai.cpp:16:
./ship/ship.h: In constructor ‘ship_type_info::ship_type_info()’:
./ship/ship.h:892: warning: ‘ship_type_info::weapon_bools’ will be initialized after
./ship/ship.h:889: warning: ‘float ship_type_info::debris_max_speed’
./ship/ship.h:919: warning: when initialized here
ai/ai.cpp: In function ‘int ai_get_slot(int)’:
ai/ai.cpp:37: warning: deprecated conversion from string constant to ‘char*’
make[1]: *** [ai.o] Error 1
make[1]: Leaving directory `/home/kasperl/freespace/fs2_open/code'
make: *** [all-recursive] Error 1
Which doesn't give me much of a hint where the compiling is going wrong. Some of it may be due to AMD64 as an arch, but I haven't the skills to investigate this much further without actually checking all the code, which I don't fancy.
-
/usr/include/gnu/stubs.h:9:27: error: gnu/stubs-64.h: No such file or directory
I'd start to look there.
-
Err. Yeah.
I'm pretty sure I've got a normal build environment. It's sane according to autoconf, after all :P Without joking, I've compiled a few programs on this system, without many issues. In case of a missing dependency I'd expect a slightly more polite error, especially because you wouldn't want to scare of the noobs.
Any ideas on what I'm missing, BTW? I've had a look around and I've got the only thing in the Debian repositories called 'stubs': "libpthread-stubs0-dev" as well as the non-dev package. There isn't a 64 bit special version for that, as far as I can see.
-
I have compiled on 64bit ubuntu, never tried on 64bit Debian, but figured it should be really close. I updated the wiki to split Debian and Ubuntu since the package names have split. My previous nightly box was my friend's 32bit Debian environment, so I know it also works fine in that situation. Not sure what's special about 64bit Debian.
build-essential did fully install right? Check that you have the 64bit version of libc6-dev installed. Quick googling led me to here (http://ubuntuforums.org/archive/index.php/t-370114.html) and here (https://bugzilla.redhat.com/show_bug.cgi?id=446705). I'm guessing you're on GCC 4.2, and possibly one of the non-stable versions of Debian?
-
I'm installing libc6-dev-amd64 now, see if it helps. Build-essential and such have been installed a long time ago, as have most of the other libs. I re-checked, but most of it was already on the system. I'm running Lenny (stable), without much in way of backports, btw. It's making now, I'll post again if it works or not.
-
Ok, that one did something, it now crashes further on. Might be nice to include that lib in the dependency lists or something.
It now crashes here:
g++ -m64 -march=athlon64 -ansi -DLUA_USE_LINUX -g -Os -Wall -funroll-loops -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/libpng12 -I/usr/include/lua5.1 -fsigned-char -Wno-unknown-pragmas -Wno-deprecated -Wno-char-subscripts -g -L/usr/lib -lSDL -L/home/kasperl/fsobin/lib -lvorbis -lm -lvorbisfile -L/home/kasperl/fsobin/lib -ltheora -L/home/kasperl/fsobin/lib -logg -L/home/kasperl/fsobin/lib -lopenal -lpng -L/home/kasperl/fsobin/lib -lGL -lGLU -lpng12 -llua5.1 -ljpeg -o fs2_open_r freespace.o levelpaging.o libcode.a
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.so when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.a when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/lib/gcc/i486-linux-gnu/4.3.2/../../../libSDL.so when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/lib/gcc/i486-linux-gnu/4.3.2/../../../libSDL.a when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libSDL.so when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libSDL.a when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.so when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.a when searching for -lSDL
/usr/bin/ld: cannot find -lSDL
collect2: ld returned 1 exit status
make[1]: *** [fs2_open_r] Error 1
make[1]: Leaving directory `/home/kasperl/freespace/fs2_open/code'
make: *** [all-recursive] Error 1
I've got the following installed:
kasperl@calvados:~/freespace/fs2_open$ dpkg --get-selections | grep sdl
gstreamer0.10-sdl install
libsdl-gfx1.2-4 install
libsdl-gfx1.2-dev install
libsdl-image1.2 install
libsdl-mixer1.2 install
libsdl-net1.2 install
libsdl-sound1.2 install
libsdl-sound1.2-dev install
libsdl-ttf2.0-0 install
libsdl1.2-dev install
libsdl1.2debian install
libsdl1.2debian-alsa install
vlc-plugin-sdl install
What am I missing?
edit: I've installed some more, just for the fun of it:
gstreamer0.10-sdl install
libsdl-console install
libsdl-console-dev install
libsdl-gfx1.2-4 install
libsdl-gfx1.2-dev install
libsdl-image1.2 install
libsdl-image1.2-dev install
libsdl-mixer1.2 install
libsdl-mixer1.2-dev install
libsdl-net1.2 install
libsdl-net1.2-dev install
libsdl-pango-dev install
libsdl-pango1 install
libsdl-sge install
libsdl-sge-dev install
libsdl-sound1.2 install
libsdl-sound1.2-dev install
libsdl-ttf2.0-0 install
libsdl-ttf2.0-dev install
libsdl1.2-dev install
libsdl1.2debian install
libsdl1.2debian-alsa install
vlc-plugin-sdl install
Didn't work, same error.
-
It almost seems as if you have a 32bit or otherwise incompatible version of libSDL installed. If it's 1.2, the version is fine so I don't know why it would be an issue. Did you get a 64bit dev lib or compile it yourself for 64bit?
-
Aptitude generally does all the architectural stuff, I just install the right packages and it figures out what versions to grab. I'll reinstall all the packages, see if it helps.
edit:
Bugger:
(Reading database ... 327432 files and directories currently installed.)
Preparing to replace libsdl-console-dev 1.3-5 (using .../libsdl-console-dev_1.3-5_i386.deb) ...
Unpacking replacement libsdl-console-dev ...
Preparing to replace libsdl-gfx1.2-dev 2.0.13-4 (using .../libsdl-gfx1.2-dev_2.0.13-4_i386.deb) ...
Unpacking replacement libsdl-gfx1.2-dev ...
Preparing to replace libsdl-image1.2-dev 1.2.6-3 (using .../libsdl-image1.2-dev_1.2.6-3_i386.deb) ...
Unpacking replacement libsdl-image1.2-dev ...
Preparing to replace libsdl-mixer1.2-dev 1.2.8-4 (using .../libsdl-mixer1.2-dev_1.2.8-4_i386.deb) ...
Unpacking replacement libsdl-mixer1.2-dev ...
Preparing to replace libsdl-net1.2-dev 1.2.7-2 (using .../libsdl-net1.2-dev_1.2.7-2_i386.deb) ...
Unpacking replacement libsdl-net1.2-dev ...
Preparing to replace libsdl-pango-dev 0.1.2-4 (using .../libsdl-pango-dev_0.1.2-4_i386.deb) ...
Unpacking replacement libsdl-pango-dev ...
Preparing to replace libsdl-sge-dev 030809dfsg-2 (using .../libsdl-sge-dev_030809dfsg-2_i386.deb) ...
Unpacking replacement libsdl-sge-dev ...
Preparing to replace libsdl-sound1.2-dev 1.0.3-2 (using .../libsdl-sound1.2-dev_1.0.3-2_i386.deb) ...
Unpacking replacement libsdl-sound1.2-dev ...
Preparing to replace libsdl-ttf2.0-dev 2.0.9-1 (using .../libsdl-ttf2.0-dev_2.0.9-1_i386.deb) ...
Unpacking replacement libsdl-ttf2.0-dev ...
Preparing to replace libsdl1.2-dev 1.2.13-2 (using .../libsdl1.2-dev_1.2.13-2_i386.deb) ...
Unpacking replacement libsdl1.2-dev ...
I'll have a go at googling about architectures and debian.
edit2: There's and am64-libs-dev package, wonder what that does...
edit3: Provide some basic support in case you need to cross-compile from i386, which isn't exactly the point today.
-
Yeah I've never done 64bit Debian before, but it sounds like your build env needs some TLC.
-
Thing is, I've compiled some other stuff (RawTherapee, some custom music software, etc) on this environment and it always works fine, except maybe for missing libs. Where there any special tricks to 64 bit Ubuntu?
-
Nope, build-essential pulled in pretty much all that stuff I think.
-
For the record, it is very unwise to build on a system that you installed as ia32, and run with an AMD64 kernel.
Also, compiling works, but executing gives me
Unrecognized command line parameter "-alpha_env". Ignoring...
Error: "FreeSpace2/Fred2 cannot be run from a drive root directory!"
It's in /freespace, because root was the only partition where I had some space and was ext3, since executing stuff on ntfs is always a pain in the arse.
Ideas?
EDIT: I'm not giving it any command-line parameters and there isn't an ini file in that folder (everything is called nini or noni or something quite different), so I haven't the faintest clue where it's getting the command line from.
-
Check ~/.fs2_open. Unix builds save their config files there.
As for the other thing, compile a debug build, run it, then post the log (which will be written to ~/.fs2_open/data).
-
~/.fs2_open/fs2_open.ini:
[Default]
VideocardFs2open=OGL -(640x480)x16 bit
Nothing odd here, right? Same output from the executable. I first removed ~/.fs2_open* since I've tried this before a long time ago, and wanted to be sure nothing would get in the way.
edit: compiling debug now.
Also, the --prefix= option in configure doesn't seem to do much, the executable keeps popping up in fs2_open/code. Which is odd.
edit2: Debug gives exactly the same output, and doesn't write anything in ~/.fs2_open.
-
fs2_open/code is just the default build drop for the make process, why's that odd?
-
Since I'd expect everything either in /usr/bin and such or in whatever --prefix mentions. But meh, I could find it. More interestingly, why can I not run FSO from the folder it's currently in? I've tried moving it about, but that didn't help anything. Is there any problem with running from ext3? Should I be doing fancy stuff to make it run from a FAT partition or something?
-
No, it should run perfectly fine if run from the same directory containing all the vp files.
-
kasperl@calvados:/freespace$ ls
data
DeusExMachina
errorlog.txt
fs2_open
fs2_open_3_6_10
fs2_open_3_6_10d
fs2_open.bin
fs2_open-debug
fs2_open-debug.bin
fs2_open_INF_d
fs2_open_INF_r
fs2_open.png
Installer
launcher6.nini
launcher6.noni
lib
linux_debug
linux_release
mediavps
mod.nini
patchw32.dll
root_fs2.vp
smarty_fs2.vp
sparky_fs2.vp
sparky_hi_fs2.vp
stu_fs2.vp
tango1_fs2.vp
tango2_fs2.vp
tango3_fs2.vp
uninstall
warble_fs2.vp
-
On Linux and OSX the current working directory must be the FreeSpace game directory, it does not matter where the binary is located.
This is different from the behaviour on windows where the physical location of the binary is made to be the working directory that the game uses to load the data from.
But assuming you are running it from the directory that you just listed, we still need the fs2_open.log from the ~/.fs2_open/data/ folder.
-
kasperl@calvados:~$ cd /freespace/
kasperl@calvados:/freespace$ ls
data fs2_open-debug.bin linux_debug sparky_hi_fs2.vp
DeusExMachina fs2_open_INF_d linux_release stu_fs2.vp
errorlog.txt fs2_open_INF_r mediavps tango1_fs2.vp
fs2_open fs2_open.png mod.nini tango2_fs2.vp
fs2_open_3_6_10 Installer patchw32.dll tango3_fs2.vp
fs2_open_3_6_10d launcher6.nini root_fs2.vp uninstall
fs2_open.bin launcher6.noni smarty_fs2.vp warble_fs2.vp
fs2_open-debug lib sparky_fs2.vp
kasperl@calvados:/freespace$ ./linux_debug
Error: "FreeSpace2/Fred2 cannot be run from a drive root directory!"
kasperl@calvados:/freespace$ ls -laR /home/kasperl/.fs2_open/
/home/kasperl/.fs2_open/:
total 20
drwxr-xr-x 2 kasperl kasperl 4096 2010-07-17 21:34 .
drwxr-x--x 141 kasperl kasperl 12288 2010-07-18 10:28 ..
-rw-r--r-- 1 kasperl kasperl 50 2010-07-17 21:32 fs2_open.ini
kasperl@calvados:/freespace$
It's simply not there... I'd post it if I could.
-
Interesting.
If I use the FS dir of my Windows partition, but leave the executable where it is now, it runs. Extremely slow, but it runs. So it is not possible to have the data and the executable on the same folder on Linux, apparently.
Even more interesting, copying the executable to another folder and running it while in the /freespace folder won't work.
Is there a serious limit on the kind of path where the data is placed?
-
Okay, I have now checked the code and it seems the check for the root directory happens sooner than I thought so the log is never gets opened.
But in looking at the code, I have found the cause for your problems. It seems that the function that checks to see if the game is being run from a root directory (like c:/) does not seem to make any distinction for UNIX systems, so "/freespace" is considered the same as "c:/", because it only has one slash. Thus, it considered a "root" directory. The easiest way to fix this would be to just move freespace to (for example) "/games/freespace" or to somehow get two slashes in the path ("/freespace/freespace") would also work.
-
Damn I almost suggested using /games/freespace2 and thought, nah, that's silly.
-
I pretty much guessed this was something forgotten in making the game cross-platform. The only reason I moved it to /freespace was because I was having issues at first with the executable located on a NTFS drive. That's all fixed now.
I suppose an OS check (even at compile time would do) would fix this?
As for the game running slowly, that's an OGL issue which I'll have to fix first. I'll post once I get that going.
-
It could be fixed in code I'm sure, file a bug if you want, but there's a fairly simple workaround for now I guess.
-
Oh, for me it works, but this either needs to go into the documentation or be fixed. It's a pain for new users, and it's odd. If you tell me which file the check is in I'll submit a patch soonish.
edit: in /code/cfile/cfile.cpp:
155,160d154
< #if defined SCP_UNIX
< // /freespace works, / shouldn't
< if(token_count <= 1){
< return 1;
< }
< #endif
-
Index: code/cfile/cfile.cpp
===================================================================
--- code/cfile/cfile.cpp (revision 6294)
+++ code/cfile/cfile.cpp (working copy)
@@ -147,9 +147,14 @@
token_count++;
tok = strtok(NULL, DIR_SEPARATOR_STR);
} while(tok != NULL);
-
- // root directory if we have <= 1 slash
+
+#ifdef SCP_UNIX
+ // /freespace works, / does not
+ if(token_count <= 1) {
+#else
+ // C:/freespace works, C:/ does not
if(token_count <= 2){
+#endif
return 1;
}
I have tested this on both Ubuntu and Windows 7.
-
Definitely better then what I did, thanks.
-
Committed in r6316, and on my list to backport after a bit more testing.