Can’t install 32 bit gstreamer-ffmpeg normally, library can’t find other 32 bit libs

32bitffmpeglibraries

I'm on Ubuntu 12.04 64 bits and I'm trying to get a game (GTA SA) working in wine, but it keeps crashing. After reading error logs it seems I needed some 32 bit versions of gstreamer, probably to play the intro video. I already have ia32-libs, because I read somewhere I will need that in order to run 32 bit software. I first tried:

sudo apt-get install gstreamer0.10-ffmpeg:i386

Which returns:

 gstreamer0.10-ffmpeg:i386 : Depends: libavcodec53:i386 (>= 4:0.7.3-1) but it is not going to be installed or
                                      libavcodec-extra-53:i386 (>= 4:0.7.3-1) but it is not going to be installed

And it also depends on libavformat, libpostproc and libswscale with about the same error. So I kept searching and found a nice tool, getlibs, which allows you to install 32 bit libraries. I think it just places them in the /usr/lib32 directory, which probably isn't the best way to do this, but I tried it anyway.

So I installed the 32 bit libraries with getlibs which wine was complaining about. Now I got different errors, basically the 32 bit library is referencing other libraries which it now can't find. For example one of the errors says:

Failed to load plugin '/usr/lib32/gstreamer-0.10/libgstffmpeg.so': libavformat.so.53: cannot open shared object file: No such file or directory

So my initial thought was correct, since it now uses the 32 bit version. Now I was trying to figure it out with ldd to see where the library references other libraries:

# This one is fine
ldd /usr/lib/gstreamer-0.10/libgstffmpeg.so | grep avformat
libavformat.so.53 => /usr/lib/x86_64-linux-gnu/libavformat.so.53 (0x00007f8314181000)

# This one isn't
ldd /usr/lib32/gstreamer-0.10/libgstffmpeg.so | grep avformat
libavformat.so.53 => not found

So indeed, libgstffmpeg.so can't find the correct libavformat.so. I tried installing the 32 bit version of libavformat with getlibs again, which placed it in /usr/lib32/i386-linux-gnu/libavformat.so. But ldd still tells me it can't find libavformat. Then I tried to make a symbolic link in the same directory but named it libavformat.so.53 and even made a symlink to `/usr/lib/i386-linux-gnu/libavformat.so.53', but both give me the same error.

Now I am sure this really isn't the correct way to go, but I didn't know the right way to do it. So what is the correct way to do this, or does gstreamer0.10-ffmpeg simply doesn't have 32 bit or multilib support? And how can I find out what the directory is, where libgstffmpeg (or any library I guess) checks for it's 32 bit libs it is referencing?

Best Answer

Try:

ldconfig -p | grep lib32

If you see no output, this is because the linker cache (read the first paragraph of man ldconfig, and about the -p switch) does not reference /usr/lib32. I checked a ubuntu 12.04 system and that is not in there by default. You can add it to: /etc/ld.so.conf.d/libc.conf which may contain just /usr/local/lib. Run just ldconfig, then the -p command from above. You should see the stuff in /usr/lib32; now try your ldd on the 32-bit gstreamer lib again.

LD

You can add a file to this directory with the path to your newly installed library like so:

$ cat /etc/ld.so.conf.d/myboost.conf
/usr/local/lib/boost1.55

Then run this command:

$ ldconfig -v

This will process all the libraries and rebuild a "cache", /etc/ld.so.cache. This cache is what's used to locate libraries when they're specified like so: -lboost_thread-mgw46-mt-sd-1_54.

Example output

$ ldconfig -v
/usr/lib64/atlas:
        libclapack.so.3 -> libclapack.so.3.0
        libptcblas.so.3 -> libptcblas.so.3.0
        libf77blas.so.3 -> libf77blas.so.3.0
        libcblas.so.3 -> libcblas.so.3.0
        liblapack.so.3 -> liblapack.so.3.0
        libptf77blas.so.3 -> libptf77blas.so.3.0
        libatlas.so.3 -> libatlas.so.3.0
/usr/lib64/wxSmithContribItems:
        libwxflatnotebook.so.0 -> libwxflatnotebook.so.0.0.1
...

When adding paths to the setup, I like to confirm by going through this output to make sure things are getting picked up the way I expect them to.

LD's cache

You can always print the contents of the .cache file as well using this command:

$ ldconfig -p | head -10
2957 libs found in cache `/etc/ld.so.cache'
    lib3ds-1.so.3 (libc6,x86-64) => /usr/lib64/lib3ds-1.so.3
    libzvbi.so.0 (libc6,x86-64) => /usr/lib64/libzvbi.so.0
    libzvbi-chains.so.0 (libc6,x86-64) => /usr/lib64/libzvbi-chains.so.0
    libzrtpcpp-1.4.so.0 (libc6,x86-64) => /usr/lib64/libzrtpcpp-1.4.so.0
    libzmq.so.1 (libc6,x86-64) => /usr/lib64/libzmq.so.1
    libzmq.so (libc6,x86-64) => /usr/lib64/libzmq.so
    libzipios.so.0 (libc6,x86-64) => /usr/lib64/libzipios.so.0
    libzipios.so (libc6,x86-64) => /usr/lib64/libzipios.so
    libzip.so.1 (libc6,x86-64) => /usr/lib64/libzip.so.1

Why's my ldd output still using 1.53?

This is because your binary is using dynamic libraries. So when the binary was compiled, it was against the 1.55 versions of the libraries. However when you interrogate the binary using ldd, it's within the environment that's using the contents of the .cache file. So the library within the cache that is associated with the symbols used by this binary match those for 1.53, hence you're seeing those libraries.

Your environment knows nothing of the 1.55 libraries, only your build environment, i.e. your Makefile, is aware of this.

Dynamic libraries

Think of the functions within these as symbols. The symbols are a name, and so these names often don't change from one version of a library to another. So if you were to look at a library such as boost, you can use the tool readelf to get a list of the symbols within one of these .so files.

Example

$ readelf -Ws /usr/lib64/libboost_date_time-mt.so | head -10

Symbol table '.dynsym' contains 261 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 000000335aa096a8     0 SECTION LOCAL  DEFAULT    9 
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _ZNSt8bad_castD2Ev@GLIBCXX_3.4 (2)
     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _ZNSt6locale5_ImplD1Ev@GLIBCXX_3.4 (2)
     4: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND _ZTINSt6locale5facetE@GLIBCXX_3.4 (2)
     5: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND wcslen@GLIBC_2.2.5 (3)
     6: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND _ZTISt11logic_error@GLIBCXX_3.4 (2)

In the above output you can see some of the FUNC definitions, these are the names that are used to "link" a function in an executable with a function from some .so library.

I'm over simplifying this, and probably explaining things slightly off, but I'm only trying to give you a general idea of how the mechanics of how the machinery under the hood works.

References

How do I list the symbols in a .so file

Best Answer

Related Solutions

Centos – ldd tells me the app is “not a dynamic executable”

Boost Library – Resolving Confusion About Linking Boost Library During Compilation

LD