Shared libraries and dependencies -- why are these still a major problem in Linux?

Valery Reznic · 06-30-2013, 04:44 PM

Quote:

Originally Posted by Xenphor

Code:

~/Downloads/ErmineLightTrial.x86_64 --output retroarch /usr/bin/retroarch 
elf_scan: can't mmap pt_load '/usr/lib/nvidia-319/libnvidia-glcore.so.319.23': 'Invalid argument' (errno=22)

Here's a ppa for it: https://launchpad.net/~hunter-kaller/+archive/ppa

There's also a frontend retroarch-phoenix that I would also pack but not sure how that would work.

I am using 64 bit Ubuntu 13.04 so I'm guessing that it's building a 64bit build.

Strange. OK, could you post output of following:

Code:

ldd /usr/bin/retroarch

Code:

file /usr/bin/retroarch

Code:

file /usr/lib/nvidia-319/libnvidia-glcore.so.319.23

Xenphor · 06-30-2013, 08:26 PM

Code:

$ ldd /usr/bin/retroarch
        linux-vdso.so.1 =>  (0x00007fffdedfe000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb3222d9000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fb3220d1000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb321eb3000)
        libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007fb321bc9000)
        libopenal.so.1 => /usr/lib/x86_64-linux-gnu/libopenal.so.1 (0x00007fb321970000)
        libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007fb321727000)
        libSDL-1.2.so.0 => /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 (0x00007fb321490000)
        libGL.so.1 => /usr/lib/nvidia-319/libGL.so.1 (0x00007fb321162000)
        libXv.so.1 => /usr/lib/x86_64-linux-gnu/libXv.so.1 (0x00007fb320f5b000)
        libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fb320c21000)
        libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fb320a0f000)
        libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007fb320808000)
        libCg.so => /usr/lib/x86_64-linux-gnu/libCg.so (0x00007fb31f32f000)
        libCgGL.so => /usr/lib/x86_64-linux-gnu/libCgGL.so (0x00007fb31f1ab000)
        libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007fb31ee47000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb31ec43000)
        libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007fb31e9a6000)
        libSDL_image-1.2.so.0 => /usr/lib/x86_64-linux-gnu/libSDL_image-1.2.so.0 (0x00007fb31e787000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fb31e570000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb31e1a8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fb3225fd000)
        libjson.so.0 => /lib/x86_64-linux-gnu/libjson.so.0 (0x00007fb31df9e000)
        libpulsecommon-3.0.so => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-3.0.so (0x00007fb31dd3b000)
        libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007fb31daf7000)
        libpulse-simple.so.0 => /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x00007fb31d8f2000)
        libcaca.so.0 => /usr/lib/x86_64-linux-gnu/libcaca.so.0 (0x00007fb31d625000)
        libnvidia-tls.so.319.23 => /usr/lib/nvidia-319/tls/libnvidia-tls.so.319.23 (0x00007fb31d421000)
        libnvidia-glcore.so.319.23 => /usr/lib/nvidia-319/libnvidia-glcore.so.319.23 (0x00007fb31aecb000)
        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fb31acad000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fb31aa8a000)
        libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007fb31a864000)
        libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007fb31a613000)
        libtiff.so.5 => /usr/lib/x86_64-linux-gnu/libtiff.so.5 (0x00007fb31a3a1000)
        libwebp.so.4 => /usr/lib/x86_64-linux-gnu/libwebp.so.4 (0x00007fb31a156000)
        libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007fb319f4c000)
        libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007fb319ce5000)
        libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007fb319adf000)
        libslang.so.2 => /lib/x86_64-linux-gnu/libslang.so.2 (0x00007fb31974f000)
        libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x00007fb319521000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fb3192f9000)
        libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fb3190f5000)
        libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fb318eee000)
        libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 (0x00007fb318ce0000)
        libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007fb318ac5000)
        libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007fb318879000)
        libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007fb3183aa000)
        libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007fb31817c000)
        libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007fb317f75000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fb317d5b000)

Code:

$ file /usr/bin/retroarch
/usr/bin/retroarch: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xd353e4269bfc6b0dd7b4a880473ea084facdce81, stripped

Code:

$ file /usr/lib/nvidia-319/libnvidia-glcore.so.319.23
/usr/lib/nvidia-319/libnvidia-glcore.so.319.23: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

Valery Reznic · 06-30-2013, 11:35 PM

Everything is normal. Could you attach your /usr/lib/nvidia-319/libnvidia-glcore.so.319.23?

Xenphor · 07-01-2013, 06:13 AM

https://dl.dropboxusercontent.com/u/....319.23.tar.gz

sundialsvcs · 07-01-2013, 06:51 AM

Quote:

Originally Posted by Xenphor

In my opinion, this is the biggest problem with any linux distribution. Is it not the reason why we can't have binary packages (like win) that don't have to be constantly maintained by someone?

Why doesn't someone make a distribution that simply includes every version of every library? And for that matter, why not include multiple versions of the Linux kernel? Is space the only issue? Because people now have multiple terrabytes of storage, so I don't think an extra 50-100gigs of install size is going to matter much, especially if that means you no longer have to worry about tracking down depedencies.

Obviously I'm sure 99% of the Linux community would hate such a distribution (they could just continue using whatever it is they were using), but I would use it. Or does this not solve any of the problems? How does Windows accomplish this?

This, basically, is what Windows does. They include the kitchen-sink. And, they maintain it all for you ... whether you like it or not.

This is also one of the reasons why Windows systems run sluggishly and are vulnerable to penetration through subsystems that you never used and don't even know exist.

Linux "Distros" often do include a "kitchen sink" option. However, that is a truly-vast amount of software ... commensurate with the "Professional" version of Windows "and then some."

Valery Reznic · 07-01-2013, 07:17 AM

Quote:

Originally Posted by Xenphor

https://dl.dropboxusercontent.com/u/....319.23.tar.gz

Thanks.

Could you try this:
http://magicermine.com/ErmineProTrial.x86_64

Version should be 3.2.1-beta and it should work

Xenphor · 07-01-2013, 08:28 AM

Quote:

Originally Posted by Valery Reznic

Thanks.

Could you try this:
http://magicermine.com/ErmineProTrial.x86_64

Version should be 3.2.1-beta and it should work

Okay I got a binary. I'll try it in a Fedora live image or something.

Quote:

This, basically, is what Windows does. They include the kitchen-sink. And, they maintain it all for you ... whether you like it or not. This is also one of the reasons why Windows systems run sluggishly and are vulnerable to penetration through subsystems that you never used and don't even know exist.

Linux "Distros" often do include a "kitchen sink" option. However, that is a truly-vast amount of software ... commensurate with the "Professional" version of Windows "and then some."

Well I haven't really seen an option for that, although it doesn't really solve the problem of aquiring older or newer libraries unless they get installed too. I think Slackware works like that, where you can install everything which makes it easier to compile programs I think. I haven't used it though.

Xenphor · 07-01-2013, 04:16 PM

Quote:

Originally Posted by Valery Reznic

Thanks.

Could you try this:
http://magicermine.com/ErmineProTrial.x86_64

Version should be 3.2.1-beta and it should work

It seemed to work in Fedora but I couldn't really test it out because I needed fonts or something.

I had a question though. This program, as well as others, uses a plugin system that uses shared libraries. Now I'm under the impression that .so, .a and so forth are binaries but just aren't executable. Is there a way to pack libraries with ermine so that their dependencies are accounted for like with executables?

Valery Reznic · 07-03-2013, 12:48 AM

Quote:

Originally Posted by Xenphor

It seemed to work in Fedora but I couldn't really test it out because I needed fonts or something.

Great!

Quote:

I had a question though. This program, as well as others, uses a plugin system that uses shared libraries. Now I'm under the impression that .so, .a and so forth are binaries but just aren't executable. Is there a way to pack libraries with ermine so that their dependencies are accounted for like with executables?

Ermine automatically pack all the libraris that reported by

Code:

ldd ./executable

If you want other files to be packaged you have following options:

1. --ld_preload
You can use it to specify additional libraries to be packed
For more info see http://magicermine.com/docs/s_ld_preload.html

2. --config
Config allows you to specify any files, not only shared libraries.
For more info see http://magicermine.com/docs/s_config.html

Xenphor · 07-03-2013, 10:42 AM

Well I guess I'm not sure what I'm asking exactly. Say for example, you want to pack the latest version of libsdl or some other library. Now, to compile that from source would require dependencies right? So, is there a way you could pack the compiled library with the dependencies so that it will function on another system?

Valery Reznic · 07-04-2013, 08:17 PM

Quote:

Originally Posted by Xenphor

Well I guess I'm not sure what I'm asking exactly. Say for example, you want to pack the latest version of libsdl or some other library. Now, to compile that from source would require dependencies right? So, is there a way you could pack the compiled library with the dependencies so that it will function on another system?

Sure. When you compiled (and probably installed) whatever libraris you need you have to specify for Ermine --ld_library_path, so those libraries will be picked up.
Or you may choose another way - much more simple, IMO. In the VM install Linux distro
which has desired version of this progam "native". Pack it using Ermine there,
and then copy to anyother distro