Installation trouble on gentoo/amd64

[moonmonster]

Hi,

First up, thanks for the Linux version. Now when I get it working I won't have to reboot any more. (It's *so* annoying to have to close down all my terminals just to play a game).

I'm currently having trouble installing darwinia on my Gentoo amd64 box. I've downloaded the installer and when I run it, it simply uncompresses something and then exits... But I can't find the uncompressed files(s) anywhere.

Here's what I see from the console:

Code: Select all

simon@moonunit ~ $ /bin/sh downloads/darwinia-full-1.1.2.sh
Verifying archive integrity... All good.
Uncompressing Darwinia full 1.1.2...................................................................
simon@moonunit ~ $

That's it. I can't find anything darwinia-related under my home directory, so I guess something went wrong:

Code: Select all

simon@moonunit ~ $ find -iname '*darwinia*'
./downloads/darwinia-full-1.1.2.sh
simon@moonunit ~ $

I've tried the above both with and without the cd mounted. No dice. What should be happening? How do I fix it?

Incidentally, while I'm here: Will there be any problems copying my savegames from my Windows version to Linux? I'd prefer not to start over from scratch again.

[edit] It might be useful to point out that I run quite a 'slim' system, so I don't have much of Gnome or any of KDE installed. (Running enlightenment instead) - Do I need any specific libraries to make it work? [/edit]

[Bruce42]

It uses the loki installer, which has two binaries. It has a dynamically linked GTK binary and if that fails it should fall back to a statically linked ncurses binary. Typically you would install as root, though it doesnt really matter (provided you have access to the CD).

Someone on IRC reported the same issue as you have here, which doesnt even seem to be running the launching script, I have no idea why.

Try this:

sh downloads/darwinia-full-1.1.2.sh --keep --target darinst

That should create a darinst directory with the installer. From there run ./setup.sh to launch the installer. If that doesnt work please post back any reason it gives.

If you are stuck you can get the files out of that directory and do a manual install.

[moonmonster]

No dice with running setup.sh manually. I can perform a manual install, but I thought this information might be of use:

I edited setup.sh to perform a trace, and here's the output.

Code: Select all

simon@moonunit ~/darinst $ ./setup.sh
++ dirname ./setup.sh
+ cd .
+ FATAL_ERROR='Fatal error, no tech support email configured in this setup'
+ GET_ROOT=0
+ XSU_ICON=
+ USE_XHOST=0
+ SU_MESSAGE='You need to run this installation as the super user.\nPlease enter the root password.'
+ NULL=/dev/null
+ test -d /usr/xpg4/bin
++ DetectARCH
++ status=1
++ case `uname -m` in
+++ uname -m
++ echo amd64
++ status=0
++ return 0
+ arch=amd64
++ DetectLIBC
++ status=1
+++ uname -s
++ '[' Linux '!=' Linux ']'
+++ echo /lib/libc.so.6
+++ tail -n 1
++ '[' -f /lib/libc.so.6 ']'
++ fgrep GLIBC_2.1 /lib/libc.so.6
++ echo glibc-2.0
++ status=0
++ return 0
+ libc=glibc-2.0
++ DetectOS
+++ uname -s
++ os=Linux
++ test Linux = OpenUNIX
++ echo Linux
++ return 0
+ os=Linux
+ args=
+ '[' -f setup.data/config.sh ']'
+ . setup.data/config.sh
+ PATH=/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/3.4.3:/usr/X11R6/bin:/opt/blackdown-jdk-1.4.2.01/bin:/opt/blackdown-jdk-1.4.2.01/jre/bin:/usr/qt/3/bin:/usr/kde/3.3/bin:/opt/vmware/bin:/usr/ucb
+ auth=0
+ '[' '' = -auth ']'
+ '[' 0 -eq 1 ']'
+ '[' 0 -eq 0 ']'
+ '[' 0 -ne 0 ']'
+ try_run setup.gtk
+ absolute=0
+ '[' setup.gtk = -absolute ']'
+ fatal=0
+ '[' setup.gtk = -fatal ']'
+ setup=setup.gtk
+ shift
+ failed=0
+ '[' 0 -eq 0 ']'
+ setup_bin=setup.data/bin/Linux/amd64/glibc-2.0/setup.gtk
+ '[' '!' -f setup.data/bin/Linux/amd64/glibc-2.0/setup.gtk ']'
+ setup_bin=setup.data/bin/Linux/amd64/setup.gtk
+ '[' '!' -f setup.data/bin/Linux/amd64/setup.gtk ']'
+ failed=1
+ '[' 1 -eq 1 ']'
+ '[' 0 -eq 1 ']'
+ return 1
+ status=1
+ '[' 1 -eq 2 ']'
+ exit 1

It's looking for a file called setup.gtk inside setup.data/bin/Linux/amd64, which doesn't exist. There is only a setup.data/bin/Linux/x86 directory, not amd64 alternative.

I tried symlinking setup.data/bin/Linux/amd64 to x86, but it still failed. This time it's because it's looking for setup.gtk inside the glibc-2.0 directory, and it only exists inside the glibc-2.1 directory. (I'm running glibc-2.3.4)

I could keep trying, but I'd rather give up and just do a manual install at this stage. But if anyone wants me to test something else I'll gladly give it a shot.

[Bruce42]

OK I do not know enough about how x86-64 is meant to work, but it is failing because your arch is amd64, and this is an x86 client and installer. If you have the required libraries and kernel support it should work anyway. Try getting 'linux32'.

[moonmonster]

I have the 32-bit emulation layer already installed. I am quite capable of running a 32-bit binary on my system. What *should* be happening, is that the installer should be falling back to x86 when it can't find anything specifically for amd64. But I guess that hasn't been imlemented.

I would have thought that the symlink would have fixed it, but then I ran into the glibc problem.

However: out of curiosity I did try and see what happened if I linked setup.gtk into the glibc-2.0 directory. It worked! At least partially... I'm actually logged into my box remotely so I can't start SDL (and therefore darwinia) until I get home so I won't know for sure... But it installed *something* anyway.

Here's an overview of how I solved the problem:

Code: Select all

simon@moonunit ~ $ /bin/sh downloads/darwinia-full-1.1.2.sh --keep --target darinst
Verifying archive integrity... All good.
Uncompressing Darwinia full 1.1.2...................................................................
simon@moonunit ~ $ cd darinst
simon@moonunit ~/darinst $ ln -s x86 setup.data/bin/Linux/amd64
simon@moonunit ~/darinst $ ln -s x86 bin/Linux/amd64
simon@moonunit ~/darinst $ ln -s ../glibc-2.1/setup.gtk setup.data/bin/Linux/x86/glibc-2.0/setup.gtk
simon@moonunit ~/darinst $ ln -s ../glibc-2.1/xsu setup.data/bin/Linux/x86/glibc-2.0/xsu
simon@moonunit ~/darinst $ ./setup.sh

I at least ended up with a /home/simon/darwinia directory that contains a darwinia binary and the game data files, so I'm pretty sure that should work. I'll be able to confirm that it works when I get home.

[Creideiki]

Or you could use the ebuild from Gentoo bug 85836, which seems to bypass the Loki installer and unpacks the game the way Gentoo thinks it should be done. It's still experimental, but works for me.

[Bruce42]

Your syntax for ln looks broken.

I think the glibc issue must be related to AMD64.

[moonmonster]

Hehe, I should've known there'd be an ebuild already. I don't know why I didn't check.

I think you're right about the glibc issue. I've just tried running the installer on my (also Gentoo) x86 workstation with the same glibc version and it launches without any problems.

There's nothing wrong with my sytax for ln... Why do you think it's wrong?

[edd8990]

Probababley no help, but

I had this problem... but SuSE had a very simple solution - it has a seperate console for running 32 bit apps, and using that solved the problem, but I suppose Gentoo doesn't have that...

[catdog]

I had the same problem, I got the ebuild working with

Code: Select all

USE="cdinstall" emerge darwinia

Brilliant game so pleased there's a Linux verson ...

I also had the same problem in Suse and was a bit curious to why there was a 32bit console ... now I know, thanks

[moonmonster]

Just FYI, the method I used above to install darwinia worked perfectly. It works with my savegames copied from Windows too...

I got a message about lspci not being installed when I ran it from the console (why does it need this??) and I don't have it installed, but it doesn't seem to affect the running of the game at all.

I guess this is a bug for the loki installer people more than the Darwinia devs... ?

[Bruce42]

lspci was used for beta protection, it is not needed any more.

The target in ln should be relative to the working directory, not the link directory.

[moonmonster]

The target in ln should be relative to the working directory, not the link directory.

No, that's incorrect. Symlinks (ln -s) are relative to the link itself. Try it out!

Code: Select all

$ cd ~
$ mkdir test
$ echo "I'm a lonely little petunia in an onion patch" > test/test.txt
$ ln -s test.txt test/petunia.txt
$ cat test/petunia.txt
I'm a lonely little petunia in an onion patch
$

(Hardlinks, on the other hand, are entirely different beasts...)

[Cargo Cult]

Had this same problem on SuSE 9.2, x86_64 - I'm in Windows XP at the moment (suffering from crash bugs...) so I'll try the above later...

[edd8990]

Had this same problem on SuSE 9.2, x86_64 - I'm in Windows XP at the moment (suffering from crash bugs...) so I'll try the above later...

SuSE has a 32 bit console. Log is as root and use that.