installing on 64-bit linux (failing with autopackage and compiling)

Our old place to report Bugs, it's not used anymore. To report bugs, please read this topic.
Phil Urich
New user
Posts: 4
Joined: 03 Jan 2007, 21:34

installing on 64-bit linux (failing with autopackage and compiling)

Post by Phil Urich »

So to fill out that helpful form.  Good idea actually, guys! I've seen alotta help forums for things where it gets messy and awkward with people trying to extract what they need to know from the people requesting help.  Although in this case much of this might be superfluous, but hey, here goes:

Warzone2100 Version
2.0.5 (downloaded the .autopackage file yesterday, then after it failed I downloaded the source today)

Operating System
Linux, Kubuntu 6.10 "Edgy" AMD64, 2.6.17-10 kernel

Hardware Information
ASUS A8N-VM CSM motherboard, AMD64 X2 4400+ (Socket 939 version) CPU, GeForce 7800 GTX (PCI-Express) with the 1.0.8776 drivers (yeah, not the latest, but the latest Ubuntu packages and I haven't felt the need to update yet).


Warzone2100 Configuration
Err, haven't gotten to that part yet ;)

Bug Description
At first I thought "hey, I have to use sh right?" thinking it was basically a shell script.  Naturally this didn't work:

philurich@foundation:/media/sda7/download/games/warzone2100$ sh warzone2100-2.0.5.package
warzone2100-2.0.5.package: 33: Syntax error: "(" unexpected (expecting "fi")

So I checked the autopackage website and realized "ohhh, right, just gotta use bash....it's not just a shell script, duhhh" and I tried that.  Things appeared to be go swimmingly!  However, the download fails.  Trying to find out why I came across the information that autopackage apparently doesn't work on anything other than 32-bit x86 yet.  So, I bit the bullet and tried to compile.  After a few errors with missing things (Ubuntu doesn't have stuff like automake installed by default, alas) and going over to root to avoid persistent "permission denied" errors, I ended up doing this:
what I did in the commandline wrote: root@foundation:/media/sda7/download/games/warzone2100/warzone2100-2.0.5# sh aut
ogen.sh
+ checking for autoconf >= 2.56 ... found 2.60, ok.
+ checking for automake >= 1.8 ... found 1.9.6, ok.
+ creating acinclude.m4
+ running aclocal ...
/usr/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_GLIB
  run info '(automake)Extending aclocal'
  or see http://sources.redhat.com/automake/auto ... ng-aclocal
+ running autoheader ...
+ running autoconf ...
+ running automake ...
configure.ac: installing `./install-sh'
configure.ac: installing `./missing'
lib/framework/Makefile.am: installing `./depcomp'
configure.ac: installing `./ylwrap'
configure.ac:27: installing `./config.guess'
configure.ac:27: installing `./config.sub'
+ removing config.cache ...

Now type './configure && make' to compile.
root@foundation:/media/sda7/download/games/warzone2100/warzone2100-2.0.5# ./conf
igure && make
bash: ./configure: /bin/sh: bad interpreter: Permission denied
root@foundation:/media/sda7/download/games/warzone2100/warzone2100-2.0.5# sh ./c
onfigure && make
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C compiled
programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
As you can see, still doesn't work in the end.  As far as I can tell, the relevant portion of config.log goes like this:
config.log wrote:configure:2583: $? = 1
configure:2606: checking for C compiler default output file name
configure:2633: gcc    conftest.c  >&5
configure:2636: $? = 0
configure:2682: result: a.out
configure:2687: checking whether the C compiler works
configure:2697: ./a.out
./configure: line 2698: ./a.out: Permission denied
configure:2700: $? = 126
configure:2709: error: cannot run C compiled programs.

Now, I'm fully aware that this likely just won't work, especially (a) reading other related posts around here, and (b) just the general lack of things properly working for AMD64, but what can I say, I'm stubborn (as evidenced by my use of 64-bit Linux, I suppose!), I'd at least like to get to the point where it fails more spectacularly instead of what is likely still an foolish little mistake on my part.  I'm also trying to be able to create a .dmg file for my Mac-using friends, since we're planning on playing this LAN tomorrow at my place, and the failure of the makedmg.sh script certainly might be tied to this failure...I'm trying to take this task one step at a time, and admittedly I'm not very knowledgeable about *nix yet (but I'm trying, oh I'm trying!).

So if anyone had any ideas, that'd be awesome.  I played the game for the first time yesterday, against one of my friends using his two computers, and it was a hell of a lot of fun, so I'd love to crack the puzzle of how to install this game on as many systems as possible :)
User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: installing on 64-bit linux (failing with autopackage and compiling)

Post by DevUrandom »

Apparently you got some kind of permission problem...
configure had problems to run /bin/sh or ./a.out...
While you could set permissions on /bin/sh, you can't set them on ./a.out since that one is created by configure to check whether your C compiler works...

Do you have some special permission system installed, like SELinux or RSBAC or similar?
Is it perhaps that you use this x86_64 thing which prevents execution of non-executable code? (NX bit it was called, I think.)

I really don't have an idea how to fix this... Never saw that before.
You might ask on the Ubuntu forums for help. Maybe they know what's wrong with your build chain...
cybersphinx
Inactive
Inactive
Posts: 1695
Joined: 01 Sep 2006, 19:17

Re: installing on 64-bit linux (failing with autopackage and compiling)

Post by cybersphinx »

I don't know what the problem is, but try the following steps to see where the problem is:
1. Run as normal user, not root. You don't need root access to compile Warzone (or anything else), only to install the needed packages.
2. Compile something else, like, ehm, well, anything that uses the autotools and make. If that doesn't work, your system seems to be messed up in some way, and you should ask some Ubuntu guys about it.
3. If you can compile something else, the problem might be Warzone itself. You could try if the Makefile.raw system works (described in COMPILE).
We want information... information... information.
CattyNebulart
New user
Posts: 5
Joined: 23 Jan 2007, 16:32

Re: installing on 64-bit linux (failing with autopackage and compiling)

Post by CattyNebulart »

Edit: over max message length...

I'm also using 64-bit ubuntu nad having trouble.

(see attached file)

The above means that all the requiered packages are installed right?
The autopackage does not work.

make gives me the following

(see attached file)

I can compile other things.

make -f Makefile.raw gives:

Code: Select all

dirk@Compchan-densk:~/GameInstallers/warzone2100-2.0.5$ make -f Makefile.raw
make -f Makefile.raw -C win32
make[1]: Entering directory `/home/dirk/GameInstallers/warzone2100-2.0.5/win32'
../makerules/configure.mk:1: ../makerules/config.mk: No such file or directory
../makerules/configure.mk:7: *** You must set VERSION in ../makerules/config.mk.  Stop.
make[1]: Leaving directory `/home/dirk/GameInstallers/warzone2100-2.0.5/win32'
make: *** [win32] Error 2
any other data that can help you guys resolve this bug?
Attachments

[The extension has been deactivated and can no longer be displayed.]

User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: installing on 64-bit linux (failing with autopackage and compiling)

Post by DevUrandom »

You need PhysFS 1.0.1. Version 1.1 has a bug in the header which makes it unusable on some systems.
If you allready have 1.0.1 installed, you somehow broke the headers... Try reinstalling physfs-dev (or whatever the package is named) or using a vanilla install from http://icculus.org/physfs/.

For the Makefile.raw issue have a look here: http://wz2100.net/wiki/development:linux_compile_guide
(It says that you need to edit makerules/config.mk, which you create by copying makerules/config.mk.tmpl)
(Using the raw Makefiles wont help you in this case, as the problem is solely PhysFS related.)
Phil Urich
New user
Posts: 4
Joined: 03 Jan 2007, 21:34

Re: installing on 64-bit linux (failing with autopackage and compiling)

Post by Phil Urich »

Okay, quite a few weeks later I finally have time to get around to trying compiling again ;)

I realized that I had made one of the lamest mistakes I could possibly have make: I was trying to compile on a drive with noexec set.  Yeah, that's kindof embarrassing . . .


Now, after getting everything I could figure was required, I'm *almost* at success, but it still gets down to a nagging problem, and I honestly have no idea what it means.  Here's the end bit, after all the "checking for X.....yes" bits:
my terminal session wrote:Making all in data
make[1]: Entering directory `/media/Zyniker/down/Games/warzone2100/warzone2100-2.0.5/data'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/media/Zyniker/down/Games/warzone2100/warzone2100-2.0.5/data'
Making all in win32
make[1]: Entering directory `/media/Zyniker/down/Games/warzone2100/warzone2100-2.0.5/win32'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/media/Zyniker/down/Games/warzone2100/warzone2100-2.0.5/win32'
Making all in lib
make[1]: Entering directory `/media/Zyniker/down/Games/warzone2100/warzone2100-2.0.5/lib'
Making all in framework
make[2]: Entering directory `/media/Zyniker/down/Games/warzone2100/warzone2100-2.0.5/lib/framework'
/bin/bash ../../ylwrap resource_parser.y y.tab.c resource_parser.c y.tab.h resource_parser.h y.output resource_parser.output -- bison -y -oy.tab.c -d
updating resource_parser.h
/bin/bash ../../ylwrap strres_parser.y y.tab.c strres_parser.c y.tab.h strres_parser.h y.output strres_parser.output -- bison -y -oy.tab.c -d
updating strres_parser.h
make  all-am
make[3]: Entering directory `/media/Zyniker/down/Games/warzone2100/warzone2100-2.0.5/lib/framework'
if gcc -DHAVE_CONFIG_H -I. -I. -I.  -I../..  -g -O2  -DNDEBUG -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL -m32 -DYY_STATIC -DDEFAULT_DATADIR="/usr/local/share/warzone2100" -MT SDL_framerate.o -MD -MP -MF ".deps/SDL_framerate.Tpo" -c -o SDL_framerate.o SDL_framerate.c; \
        then mv -f ".deps/SDL_framerate.Tpo" ".deps/SDL_framerate.Po"; else rm -f ".deps/SDL_framerate.Tpo"; exit 1; fi
In file included from /usr/include/features.h:346,
                from /usr/include/sys/types.h:27,
                from /usr/include/SDL/SDL_stdinc.h:32,
                from /usr/include/SDL/SDL_main.h:26,
                from /usr/include/SDL/SDL.h:28,
                from SDL_framerate.h:20,
                from SDL_framerate.c:10:
/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory
make[3]: *** [SDL_framerate.o] Error 1
make[3]: Leaving directory `/media/Zyniker/down/Games/warzone2100/warzone2100-2.0.5/lib/framework'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/media/Zyniker/down/Games/warzone2100/warzone2100-2.0.5/lib/framework'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/media/Zyniker/down/Games/warzone2100/warzone2100-2.0.5/lib'
make: *** [all-recursive] Error 1
Actually, looking back, the problem might be showing earlier when I run automake.sh:
automake wrote:+ checking for autoconf >= 2.56 ... found 2.60, ok.
+ checking for automake >= 1.8 ... found 1.9.6, ok.
+ creating acinclude.m4
+ running aclocal ...
/usr/share/aclocal/snacc.m4:24: warning: underquoted definition of AM_PATH_SNACC
  run info '(automake)Extending aclocal'
  or see http://sources.redhat.com/automake/auto ... ng-aclocal
/usr/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_GLIB
+ running autoheader ...
+ running autoconf ...
+ running automake ...
+ removing config.cache ...
So, err, I guess the question is, what am I foolishly overlooking this time?
cybersphinx
Inactive
Inactive
Posts: 1695
Joined: 01 Sep 2006, 19:17

Re: installing on 64-bit linux (failing with autopackage and compiling)

Post by cybersphinx »

Code: Select all

/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory
Sounds like your includes are messed up somehow.
We want information... information... information.
Phil Urich
New user
Posts: 4
Joined: 03 Jan 2007, 21:34

Re: installing on 64-bit linux (failing with autopackage and compiling)

Post by Phil Urich »

cybersphinx wrote:

Code: Select all

/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory
Sounds like your includes are messed up somehow.
Alas, I know just enough to get a vague idea of what you mean; nothing that I could put towards figuring this out, though.

I have also been having problems compiling other more intensive things, though simpler things like [url=http://"http://jelmer.vernstok.nl/oss/ptabtools/"]ptabtools[/url] have worked without a hitch (though that's hardly much of a compile at all).
User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: installing on 64-bit linux (failing with autopackage and compiling)

Post by DevUrandom »

This looks to me as if the installation of some GNU headers on your system is broken. My stubs-32.h is from GLibC, so I think you should try to reinstall the development package for that library.
cybersphinx
Inactive
Inactive
Posts: 1695
Joined: 01 Sep 2006, 19:17

Re: installing on 64-bit linux (failing with autopackage and compiling)

Post by cybersphinx »

Hm, I'm running 32 bit Debian, but I hope the systems are similar enough...

For me /usr/include/gnu/stubs.h is in the package libc6-dev, to check run either

Code: Select all

dlocate -S /usr/include/gnu/stubs.h
or, if dlocate isn't available,

Code: Select all

for i in /var/lib/dpkg/info/*.list ; do grep /usr/include/gnu/stubs.h $i /dev/null ; done
Then check the Ubuntu bugreports/forums... if that issue is a known bug. If it's not, you could try reinstalling the package, and if that doesn't help, report it as a bug.

You can also do a

Code: Select all

find /usr/include | grep stubs32.h
to see if you have that file somewhere, and then adjust the path in stubs.h, though that's a very hackish solution (and might break other things...).
We want information... information... information.
Phil Urich
New user
Posts: 4
Joined: 03 Jan 2007, 21:34

a different problem is now blocking the way forward....

Post by Phil Urich »

Alright, I checked up and as far as I can tell it isn't a known bug of any kind... I did some dpkg-reconfigure on all the libc6 packages that I have installed (libc6, libc6-dev, libc6-i386, libc6-dev-i386), entirely removed and re-installed the dev ones....and I don't know if it was that or something else I'm entirely missing, but somewhere in there things got really weird!  Suddenly ./configure would fail claiming that physfs wasn't installed.  It most certainly was, though!  I tried removing it (I don't have anything installed right now that depends on it anyways) and re-installing but even that didn't work.  I did notice that the version Ubuntu has in the repos is an old version, so I just figured what the hell, I'll download the latest source and compile it.

Well, that compiled and installed quite swimmingly!  A welcome change of pace, I must say :)

However, though it now gets past physfs in the ./configure, it's complaining about SDL, which I most certainly do have installed.  It gives that classic message about "If it is not finding SDL, you'll need to set your LD_LIBRARY_PATH environment variable, or edit /etc/ld.so.conf to point to the installed location".  If I go --disable-sdltest then it gives the exact same complaint, just with Vorbis now (which also previously worked, and is also definitely installed).  I tried doing what the error suggests, but I must admit I once again don't really know what I'm doing.... nothing I ran across on google gave me a comprehensible way to go about setting my LD_LIBRARY_PATH in this instance so I just added /usr/lib to /etc/ld.so.conf and ran ldconfig.  Previously the file had looked like this:
/etc/ld.so.conf wrote:include /etc/ld.so.conf.d/*.conf
/usr/X11R6/lib
and now I have it looking like this:
/etc/ld.so.conf wrote: include /etc/ld.so.conf.d/*.conf
/usr/X11R6/lib
/usr/lib
/lib
but it's still no-go.

I'm guessing somehow I screwed up something rather fundamental?


Edit: Forced an install of the Ubuntu i386 .deb, it gives a similar error message to the setup when :

Code: Select all

warzone2100: error while loading shared libraries: libphysfs-1.0.so.0: cannot open shared object file: No such file or directory
Last edited by Phil Urich on 20 Feb 2007, 07:44, edited 1 time in total.
cybersphinx
Inactive
Inactive
Posts: 1695
Joined: 01 Sep 2006, 19:17

Re: installing on 64-bit linux (failing with autopackage and compiling)

Post by cybersphinx »

You have completely removed libc6-dev? For me that wants to remove all development packages (that are dependant on libc6-dev), so you have to reinstall all of those again (libsdl1.2-dev, libphysfs-dev etc.) as well as libc6-dev itself. The physfs problem is probably that the .deb uses physfs 1.0, while the newest version (that you probably downloaded and installed) is 1.1.

Hint for future reinstalls:

Code: Select all

apt-get install --reinstall package
That just reinstalls the package without affecting dependencies.
We want information... information... information.
User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: installing on 64-bit linux (failing with autopackage and compiling)

Post by DevUrandom »

PhysFS 1.1.0 is a development version and known to be broken. Don't use it!
CattyNebulart
New user
Posts: 5
Joined: 23 Jan 2007, 16:32

Re: installing on 64-bit linux (failing with autopackage and compiling)

Post by CattyNebulart »

When using physfs 1.0.1 instead of 1.1.0 I get the following error: so which version of physfs are we supposed to use anyway? 1.0.0-5 was also not working...

Code: Select all

/usr/bin/ld: skipping incompatible /usr/lib/libphysfs.so when searching for -lphysfs
/usr/bin/ld: skipping incompatible /usr/lib/libphysfs.a when searching for -lphysfs
/usr/bin/ld: skipping incompatible /usr/lib/libphysfs.so when searching for -lphysfs
/usr/bin/ld: skipping incompatible /usr/lib/libphysfs.a when searching for -lphysfs
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../libphysfs.so when searching for -lphysfs
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../libphysfs.a when searching for -lphysfs/usr/bin/ld: skipping incompatible /usr/bin/../lib/libphysfs.so when searching for -lphysfs
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libphysfs.a when searching for -lphysfs
/usr/bin/ld: skipping incompatible /usr/lib/libphysfs.so when searching for -lphysfs
/usr/bin/ld: skipping incompatible /usr/lib/libphysfs.a when searching for -lphysfs
/usr/bin/ld: cannot find -lphysfs
collect2: ld returned 1 exit status
cybersphinx
Inactive
Inactive
Posts: 1695
Joined: 01 Sep 2006, 19:17

Re: installing on 64-bit linux (failing with autopackage and compiling)

Post by cybersphinx »

Are you trying to link 32 bit libraries into a 64 bit binary? The error message sounds like that.
We want information... information... information.
Locked