+- Forums (https://www.vdrift.net/Forum)
+-- Forum: Community (https://www.vdrift.net/Forum/forumdisplay.php?fid=3)
+--- Forum: Bugs (https://www.vdrift.net/Forum/forumdisplay.php?fid=7)
+--- Thread: scons install fails (/showthread.php?tid=261)
scons install fails - clytle374 - 07-09-2006
Hello, I have never gotten scons install to work, I have been doing that manualy ( with a few problems) I'm on a AMD 64, FC5.
scons builds OK
scons install :
[root@localhost vdrift]# scons install
scons: Reading SConscript files ...
Checking for main() in C library openal... yes
Checking for main() in C library alut... yes
Checking for C++ header file GL/gl.h... yes
Checking for C++ header file GL/glu.h... yes
Checking for C++ header file SDL/SDL.h... yes
Checking for C++ header file SDL/SDL_image.h... yes
Checking for C++ header file SDL/SDL_net.h... yes
Checking for C++ header file AL/al.h... yes
Checking for C++ header file AL/alc.h... yes
Checking for C++ header file AL/alut.h... yes
Checking for C header file libintl.h... yes
TypeError: __call__() takes at most 4 arguments (5 given):
File "SConstruct", line 292:
SConscript('data/SConscript')
File "/usr/lib/scons/SCons/Script/SConscript.py", line 581:
return apply(method, args, kw)
File "/usr/lib/scons/SCons/Script/SConscript.py", line 508:
return apply(_SConscript, [self.fs,] + files, {'exports' : exports})
File "/usr/lib/scons/SCons/Script/SConscript.py", line 239:
exec _file_ in stack[-1].globals
File "data/SConscript", line 21:
SConscript('tracks/SConscript')
File "/usr/lib/scons/SCons/Script/SConscript.py", line 581:
return apply(method, args, kw)
File "/usr/lib/scons/SCons/Script/SConscript.py", line 508:
return apply(_SConscript, [self.fs,] + files, {'exports' : exports})
File "/usr/lib/scons/SCons/Script/SConscript.py", line 239:
exec _file_ in stack[-1].globals
File "data/tracks/SConscript", line 10:
env.Distribute (bin_dir, 'track_list.txt.full', 'track_list.txt.minimal')
File "/usr/lib/scons/SCons/Environment.py", line 149:
return apply(self.builder, (self.env,) + args, kw)
This is revision 1152 of SVN
I also checked out the new installer, Nice work, I never saw the GTK installer before looks nice. Running vdrift from installer gives.
vdrift: error while loading shared libraries: libopenal.so.0: cannot open shared object file: No such file or directory
Manual install of scons output does work, well at least as root :oops:
If you need anything else let me know, and again nice game.
Thanks
Cory
- thelusiv - 07-10-2006
What version of OpenAL do you have installed? Also what version of SCons?
I am looking into the install problem...
edit: Just for reference I'm using SCons 0.96.92 on Debian etch. The 0.96.1 version should also work (this is what we distribute as scons-local).
- clytle374 - 07-10-2006
scons -v
SCons by Steven Knight et al.:
script: v0.96.1.D001, 2004/08/23 09:55:29, by knight on casablanca
engine: v0.96.1.D001, 2004/08/23 09:55:29, by knight on casablanca
Copyright © 2001, 2002, 2003, 2004 The SCons Foundation
openal.x86_64 0.0.9-0.5.20060204cvs.
openal-devel.x86_64 0.0.9-0.5.20060204cvs.
Anthing else??
Thanks
Cory
- thelusiv - 07-10-2006
ok, I bet since you're running x86_64 the name of your libs are different and therefore it's not finding the right openal lib. Could you do something like this for me:
Code:
thelusiv@superfun:~/games/vdrift$ ls /usr/lib |grep openal
libopenal.a
libopenal.la
libopenal.so
libopenal.so.0
libopenal.so.0.0.0If things are as I expect we will need to build some x86-64 specific packages. Who wants to work on this? It's not hard to make the packages, just run something like this:
Code:
scons minimal=1 use_binreloc=1 use_apbuild=1 autopackage
).To test this file, just run it. It is a good idea to uninstall VDrift first if you haven't already, so you can be sure it installs properly. Try running the game, etc. If everything works great, then rename the file to something like "vdrift-2006-07-08-minimal.x86-64.package".
Now make another package with minimal=0. This will take a while (there's a lot of files!)
Code:
scons minimal=0 autopackageIf anyone successfully builds an x86-64 package I'll give them file release access on the VDrift project page and you can upload your packages, and also post a story on the front page announcing the packages.
- clytle374 - 07-10-2006
ls /usr/lib | grep openal
NOTA
ls /usr/lib64 | grep openal
libopenal.so
libopenal.so.0
libopenal.so.0.0.0
How do I tell Vdrift where to look?
also I'd really like to find out the scons install issue, as I'm starting to look at the code.
scons minimal=1 use_binreloc=1 use_apbuild=1 autopackage
where does this come from??
sh: makeinstaller: command not found
Thanks
Cory
- thelusiv - 07-10-2006
The binary is unable to find your libs since they are in a place other than where the ones on my system were...
To fix SCons try commenting this line: File "data/tracks/SConscript", line 10:
Code:
env.Distribute (bin_dir, 'track_list.txt.full', 'track_list.txt.minimal')Code:
#env.Distribute (bin_dir, 'track_list.txt.full', 'track_list.txt.minimal')If you can get it to compile it will probably work, scons will automatically look in the correct place to link against your libs. It uses the command
Code:
openal-config --cflags --libsAre all 64bit libraries on all distributions kept in /usr/lib64?
- alex25 - 07-10-2006
thelusiv Wrote:Are all 64bit libraries on all distributions kept in /usr/lib64?
not in debian. /usr/lib64 is a link to /usr/lib, but the libraries are installed in /usr/lib.
--alex--
- clytle374 - 07-10-2006
OK I try it, Sorry but i think we had a little race condition on this post. so i'll repeat myself
scons minimal=1 use_binreloc=1 use_apbuild=1 autopackage
where does this come from??
sh: makeinstaller: command not found
also trying to build it use_apbuild=1 says apg++ not found. Not familar with it. =0 always worked before
I commented that line and get the same error..
Cory
not in debian. /usr/lib64 is a link to /usr/lib, but the libraries are installed in /usr/lib. HOW DOES THAT MAKE SINCE??
- thelusiv - 07-10-2006
clytle374 Wrote:OK I try it, Sorry but i think we had a little race condition on this post. so i'll repeat myselfHehe, sorry about posting so fast... and editing my posts
scons minimal=1 use_binreloc=1 use_apbuild=1 autopackage
where does this come from??
sh: makeinstaller: command not found
also trying to build it use_apbuild=1 says apg++ not found. Not familar with it. =0 always worked before
you can leave out use_apbuild if you like. apg++ is available from autopackage.org. makeinstaller is available there too...sorry I forgot to mention this Try this package http://ftp.sunsite.dk/projects/autopackage/1.0.10/autopackage-devel-1.0.10.x86.package
clytle374 Wrote:I commented that line and get the same error..Hmmm...are you sure it's exactly the same? The first time it complained about that line, so at the very least it should no longer complain about it. Are you sure it's not now complaining about the similar line in data/cars/SConscript ? If so try commenting that line too. edit: for clarity, those lines are just used when building the source package.
Cory
clytle374 Wrote:not in debian. /usr/lib64 is a link to /usr/lib, but the libraries are installed in /usr/lib. HOW DOES THAT MAKE SINCE??hmmm...well as Alex said on Debian it seems they just symlink the directory to the regular lib dir. Then whenever something tries to reference /usr/lib64 it will be redirected to /usr/lib which really contains all the libs.
edit: thinking forward, maybe a good way to make differing library paths not matter is with autopackage's relaytool...alas I do not understand it yet. I will keep trying...can anyone explain it to me? It explains it relative to dlopen()/dlsym() but I know nothing about these...
- clytle374 - 07-10-2006
Quote:Hmmm...are you sure it's exactly the same? The first time it complained about that line, so at the very least it should no longer complain about it. Are you sure it's not now complaining about the similar line in data/cars/SConscript ?
Sorry didn't pay enough attention . I understand the linking lib64 to lib, but what if you have some 32 bit libs on a 64 bit machine?
I'll try commenting out more lines, as the autopackage list the same errors, but doesn't seem to fail.
And I all found the makeinstaller and well if made a package but install fails with.
sh vdrift-2006-07-08.x86.package
err:copyFile()852: FILENAME-FROM does not exist: usr/share/games/vdrift/bin/vdrift
Thanks
cory
- thelusiv - 07-10-2006
Check to make sure it's creating the temporary package directory ./tmp-vdrift-build when you run scons autopackage. it might be that it is producing an empty package because it is not creating this temporary directory properly (though it should, dangit!)
You may be able to help it by typing (in the dir where you run scons autopackage)
Code:
mkdir -p tmp-vdrift-build/usr/share/games/vdrift/bin/ tmp-vdrift-build/usr/share/games/vdrift/data/- clytle374 - 07-10-2006
scons install works after commenting out
Code:
#env.Distribute (src_dir, ['SConscript', 'track_list.txt.full', 'track_list.txt.minimal'])
#env.Distribute (bin_dir, 'track_list.txt.full', 'track_list.txt.minimal')in data/tracks/SConscript
scons minimal=1 use_binreloc=1 use_apbuild=0 autopackage
builds a file but install gives me:
Code:
Checking for required C library versions ... failed
Error: Your copy of glibc, a core system library, is too old for this package.
You need at least the following symbols in glibc: GLIBC_2.2.5.
This error normally means that whoever built the package did not build it correctly.
Please report the contents of this message to the provider of this package, and
ask them to rebuild it using apbuild.
Upgrading glibc is highly dangerous, so we recommend in this situation that you
compile the app you want to install from the sources if possible. Sorry :(
Error: Unable to prepare package VDrift.I think it is, yum list shows.
Code:
glibc.x86_64 2.4-8 installed
glibc.i686 2.4-8 installed
glibc-common.x86_64 2.4-8 installed
glibc-devel.x86_64 2.4-8 installed
glibc-devel.i386 2.4-8 installed
glibc-headers.x86_64 2.4-8 installed
glibc-kernheaders.x86_64 3.0-5.2 installedSo the use_apbuild=1 works after installing autopackage and i try that (as sujested by the installer)
Same message as above.
Another 64 bit issue? Anyway i had 32 bit installed, and it worked good. But whats the fun in that?
Any ideas? I'd like to help (my knowlege is a bit limited, but i like to learn)
Anyway, I can't type or think right anymore so Good night and thanks a bunch.
cory
- thelusiv - 07-10-2006
hmmm, it may be again misidentifying your libraries because of their alternate names...that is strange. I'm still new to this autopackage thing honestly, I'm not quite sure why it doesn't work...
Could you try compiling using scons?
Code:
scons use_apbuild=0 use_binreloc=1Code:
scons installThanks for your help testing Cory!
- clytle374 - 07-10-2006
Yes it runs the only problem i had with scons was the install failing, I had just been moving the files manualy (probably why sound often failed as non root usr). Commenting those lines makes the install work with sound as non root
and the apbuild option
Code:
scons use_apbuild=0 use_binreloc=1
scons installjust need to get autopackage to understand the glibc, when builing the package it was detected OK.
Thanks for all the teaching,
Cory
GOTTA GOTO BED
- thelusiv - 07-10-2006
Alright, that sounds good, at least you can properly build it...now to convince autpackage that it's OK.
edit: I have posted on the autopackage forums for help with this issue and others: http://autopackage.org/forums/viewtopic.php?t=403