[kasperl]

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:

Code: [Select]

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.

[The E]

Code: [Select]

/usr/include/gnu/stubs.h:9:27: error: gnu/stubs-64.h: No such file or directory
I'd start to look there.

[kasperl]

Err. Yeah.

I'm pretty sure I've got a normal build environment. It's sane according to autoconf, after all 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.

[chief1983]

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 and here.  I'm guessing you're on GCC 4.2, and possibly one of the non-stable versions of Debian?

[kasperl]

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.

[kasperl]

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:

Code: [Select]

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:

Code: [Select]

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:

Code: [Select]

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.

[chief1983]

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?

[kasperl]

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:

Code: [Select]

(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.

[chief1983]

Yeah I've never done 64bit Debian before, but it sounds like your build env needs some TLC.

[kasperl]

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?

[chief1983]

Nope, build-essential pulled in pretty much all that stuff I think.

[kasperl]

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.

[The E]

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).

[kasperl]

~/.fs2_open/fs2_open.ini:

Code: [Select]

[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.

[chief1983]

fs2_open/code is just the default build drop for the make process, why's that odd?

[kasperl]

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?

[The E]

No, it should run perfectly fine if run from the same directory containing all the vp files.

[kasperl]

Code: [Select]

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



[Iss Mneur]

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]

Code: [Select]

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.