Chaosforge Forum

  • April 02, 2020, 00:05
  • Welcome, Guest
Please login or register.



Login with username, password and session length
Pages: [1]

Author Topic: [Solved][0.9.9.5| linux] Fedora16 x64 fail to start, liblua5.1.so.0 No such file  (Read 5366 times)

d1t2

  • Private
  • *
  • Offline Offline
  • Posts: 2
  • Lost Soul
    • View Profile

Hi all,

I download 0.9.9.5 linux 32- and 64-bit version and
they do not find liblua5.1.so.0 even liblua(32- & 64-bit) symbolic link existed.

my fedora linux "uname -r": 3.1.6-1.fc16.x86_64

any suggest?


Code: [Select]
d1t2@f16:doomrl-linux-x64-0995 $ ./doomrl
./doomrl: error while loading shared libraries: liblua5.1.so.0: cannot open shared object file: No such file or directory

d1t2@f16:doomrl-linux-x64-0995 $ ls -l /usr/lib64/liblua*
-rwxr-xr-x. 1 root root 180560  4月  6  2011 /usr/lib64/liblua-5.1.so
lrwxrwxrwx  1 root root     13  1月  5 02:40 /usr/lib64/liblua-5.1.so.0 -> liblua-5.1.so

d1t2@f16:doomrl-linux-x64-0995 $ ldd ./doomrl
linux-vdso.so.1 =>  (0x00007fff141ff000)
libm.so.6 => /lib64/libm.so.6 (0x00007fe7e792f000)
liblua5.1.so.0 => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007fe7e772a000)
libz.so.1 => /lib64/libz.so.1 (0x00007fe7e7513000)
libSDL_mixer-1.2.so.0 => /usr/lib64/libSDL_mixer-1.2.so.0 (0x00007fe7e72c3000)
libSDL-1.2.so.0 => /usr/lib64/libSDL-1.2.so.0 (0x00007fe7e7023000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe7e6e07000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fe7e6ac9000)
libsmpeg-0.4.so.0 => /usr/lib64/libsmpeg-0.4.so.0 (0x00007fe7e686c000)
libc.so.6 => /lib64/libc.so.6 (0x00007fe7e64b6000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe7e7bd6000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fe7e629b000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe7e6085000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fe7e5d7e000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fe7e5b7b000)

d1t2@f16:doomrl-linux-x64-0995 $ strace ./doomrl
execve("./doomrl", ["./doomrl"], [/* 43 vars */]) = 0
brk(0)                                  = 0x2644000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f78956d9000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=138257, ...}) = 0
mmap(NULL, 138257, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f78956b7000
close(3)                                = 0
open("/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260Q\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=600096, ...}) = 0
mmap(NULL, 2633960, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f7895235000
mprotect(0x7f78952b8000, 2093056, PROT_NONE) = 0
mmap(0x7f78954b7000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x82000) = 0x7f78954b7000
close(3)                                = 0
open("/lib64/tls/x86_64/liblua5.1.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/tls/x86_64", 0x7fff536d2400) = -1 ENOENT (No such file or directory)
open("/lib64/tls/liblua5.1.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/tls", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
open("/lib64/x86_64/liblua5.1.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/x86_64", 0x7fff536d2400)   = -1 ENOENT (No such file or directory)
open("/lib64/liblua5.1.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64", {st_mode=S_IFDIR|0555, st_size=12288, ...}) = 0
open("/usr/lib64/tls/x86_64/liblua5.1.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/tls/x86_64", 0x7fff536d2400) = -1 ENOENT (No such file or directory)
open("/usr/lib64/tls/liblua5.1.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/tls", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
open("/usr/lib64/x86_64/liblua5.1.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/x86_64", 0x7fff536d2400) = -1 ENOENT (No such file or directory)
open("/usr/lib64/liblua5.1.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64", {st_mode=S_IFDIR|0555, st_size=122880, ...}) = 0
writev(2, [{"./doomrl", 8}, {": ", 2}, {"error while loading shared libra"..., 36}, {": ", 2}, {"liblua5.1.so.0", 14}, {": ", 2}, {"cannot open shared object file", 30}, {": ", 2}, {"No such file or directory", 25}, {"\n", 1}], 10./doomrl: error while loading shared libraries: liblua5.1.so.0: cannot open shared object file: No such file or directory
) = 122
exit_group(127)                         = ?

« Last Edit: January 05, 2012, 14:57 by d1t2 »
Logged

AStranger

  • First Lieutenant
  • *
  • Offline Offline
  • Posts: 233
  • Cyberdemon Blade
    • View Profile

I don't have any inside knowledge, but I'd assume the problem is with the liblua5.1.so.0 Fedora package. I don't know much about using Fedora (I use Slackware), but I'd start by removing the current lua package and installing it from the source. Installing lua from source wasn't as smooth as I usually like since I had to tweak the Makefiles but it worked in the end.

Here's the contents of lua-5.1.4-liblua.so-fix.patch:
Spoiler (click to show/hide)

The general steps I used to install lua went as follows:
Code: [Select]
$ wget http://www.lua.org/ftp/lua-5.1.4.tar.gz
$ tar zxvf lua-5.1.4.tar.gz
$ cd lua-5.1.4
$ patch -p1 -i lua-5.1.4-liblua.so-fix.patch
$ make linux
$ sudo make install
$ sudo ldconfig

Hopefully the Fedora lua package is the problem and installing lua from source fixes it. I've been able to run both the 32bit and 64bit version of DoomRL like this (the 32bit install had slightly different targets and was run under a chroot environment though). If it doesn't work then I apologize for sending you on a wild goose chase.
« Last Edit: January 07, 2012, 21:05 by AStranger »
Logged
[24|23|20|18|13] v.0.9.9.3
[17|10|8|5|2] v.0.9.9.2
[15|11|10|6|3] v.0.9.9.1
[18|17|14|10|6] v.0.9.9

nathrakh

  • Private FC
  • *
  • Offline Offline
  • Posts: 8
  • Lost Soul
    • View Profile

Got same error on 64-bit Arch Linux.

It works fine after using this command
Code: [Select]
sed -i 's/liblua5.1.so.0/liblua.so.5.1\x00/g' doomrl (copied from some comment in AUR page foor DoomRL).

However I don't get any sound even after installing bunch of libraries.
Logged

d1t2

  • Private
  • *
  • Offline Offline
  • Posts: 2
  • Lost Soul
    • View Profile

thanks AStranger, nathrakh!
i got wrong name(liblua-5.1.so.0) to link to liblua5.1.so.0, lol

it works on ubuntu(liblua5.1.so.0), but not fedora(liblua-5.1.so) or arch(liblua.so, liblua.so.5.1)


However I don't get any sound even after installing bunch of libraries.
me, too!
Logged

Kornel Kisielewicz

  • God Hand
  • Apostle
  • *
  • *
  • Offline Offline
  • Posts: 4530
    • View Profile
    • http://chaosforge.org/

Next version will link to Lua statically, so there should be no more such problems. As for the sound, I have no clue... AStranger?
Logged
at your service,
Kornel Kisielewicz

AtavisticPuma

  • Private FC
  • *
  • Offline Offline
  • Posts: 6
  • Lost Soul
    • View Profile

Same problem with sound here, but the 32bit version works fine
Logged

AStranger

  • First Lieutenant
  • *
  • Offline Offline
  • Posts: 233
  • Cyberdemon Blade
    • View Profile

Next version will link to Lua statically, so there should be no more such problems. As for the sound, I have no clue... AStranger?
The only idea I have is really stupid. When I extracted the 32-bit version the config file had both music and sound set to true. I turned off music like I always do (I really need to install a midi player or mp3s), installed lua and everything just seemed to work (sound too). I was rushing with the 64bit version so I just installed lua and made sure the main menu came up, which it did. Then I made my lua post and called it a day.

When I woke up today and tried the 64bit version, I found out there was no sound. So I checked the config file and noticed it had both the music and sound set to FALSE. At that point I decided to extract a fresh 64bit copy of DoomRL (to make sure I didn't change the config while I was high) and config.lua still had the music and sound set to false. I set sound to true and everything worked.

It looks like the 32bit ships with sound on and the 64bit ships with sound off. This was the problem for me, hopefully it's the same for everyone else. If my grammar seems a little off right now, it is because I just woke up and need coffee.
Logged
[24|23|20|18|13] v.0.9.9.3
[17|10|8|5|2] v.0.9.9.2
[15|11|10|6|3] v.0.9.9.1
[18|17|14|10|6] v.0.9.9

nathrakh

  • Private FC
  • *
  • Offline Offline
  • Posts: 8
  • Lost Soul
    • View Profile

So I checked the config file and noticed it had both the music and sound set to FALSE.
...Confirmed. However, even after installing stuff to play the midi files (timidity-stuff etc.) it just won't work for me. Luckily the .mp3's are available - they work just fine.
Logged

AStranger

  • First Lieutenant
  • *
  • Offline Offline
  • Posts: 233
  • Cyberdemon Blade
    • View Profile

...(timidity-stuff etc.)...
In DoomRL's defense, timidity is a N! to in install and configure correctly last I remember. Actually even the lua problem isn't DoomRL's fault; the reason I knew how to install lua off the top of my head was because I had run into trouble doing it before. For some reason the 5.1.4 Lua install doesn't build a liblua.so file, which doesn't make much sense for a Linux library. So every Linux distro that wanted to build a lua package had to manually make and name the .so file. Obviously this didn't lead to a standard filename, hence the initial problem of the thread.

On a complete side note, this is kinda why I don't like packages. Too many times distro maintainers make random tweeks or decisions that cause unintended problems down the line (http://www.debian.org/security/2008/dsa-1571). I'm not saying don't use packages, just that I won't use them.
« Last Edit: January 07, 2012, 20:58 by AStranger »
Logged
[24|23|20|18|13] v.0.9.9.3
[17|10|8|5|2] v.0.9.9.2
[15|11|10|6|3] v.0.9.9.1
[18|17|14|10|6] v.0.9.9

nathrakh

  • Private FC
  • *
  • Offline Offline
  • Posts: 8
  • Lost Soul
    • View Profile

Now this is getting little offtopic but it's nice information so even if I'm selfish I'll continue. (Huehuehue).

In DoomRL's defense, timidity is a N! to in install and configure correctly last I remember. Actually even the lua problem isn't DoomRL's fault; the reason I knew how to install lua off the top of my head was because I had run into trouble doing it before. For some reason the 5.1.4 Lua install doesn't build a liblua.so file, which doesn't make much sense for a Linux library. So every Linux distro that wanted to build a lua package had to manually make and name the .so file. Obviously this didn't lead to a standard filename, hence the initial problem of the thread.
Well now it makes sense.

Quote
On a complete side note, this is kinda why I don't like packages. Too many times distro maintainers make random tweeks or decisions that cause unintended problems down the line (http://www.debian.org/security/2008/dsa-1571). I'm not saying don't use packages, just that I won't use them.
If I wouldn't use pacman (Arch Linux's package manager) I would have to download, tweak, configure and compile every package myself? Hoho, way too much hassle for a newbie like me. Also, how does one update then? Guess I'd have to write some obscure scripts to keep track of updates..

To Arch Linux's defense (lol) their policy is to make minimum amount of "tweaks" to any package, preferably none at all. Almost all packages are "vanilla".
Logged
Pages: [1]