libwebp.so glibc dependency

[Herbie 0]

I installed Media Browser server on my Open Media Vault box (OMV is based on debian 7 wheezy). I installed using a plugin someone has created for OMV . I had an issue with the bundled version of libwebp.so. It seems as though it's built against a newer version of glibc that is available in debian wheezy:

$ ldd /opt/mediabrowser/libwebp/linux/lib64/libwebp.so
/opt/mediabrowser/libwebp/linux/lib64/libwebp.so: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /opt/mediabrowser/libwebp/linux/lib64/libwebp.so)
        linux-vdso.so.1 =>  (0x00007fff6c9ff000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe7eb97b000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe7eb75f000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe7eb3d3000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe7ebe62000)

This lead to several DllNotFoundException errors in the log and images were not available when browsing my library. I built version 0.4.1 locally and used this instead and that seemed to work fine.

 

This may or may not be the same issue that people are having in this thread.

 

I don't know if it would be worth including a version built against glibc 2.13 that may be usable more universally.

 

 

 

[gsnerf 26]

I installed Media Browser server on my Open Media Vault box (OMV is based on debian 7 wheezy). I installed using a plugin someone has created for OMV . I had an issue with the bundled version of libwebp.so. It seems as though it's built against a newer version of glibc that is available in debian wheezy:

$ ldd /opt/mediabrowser/libwebp/linux/lib64/libwebp.so
/opt/mediabrowser/libwebp/linux/lib64/libwebp.so: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /opt/mediabrowser/libwebp/linux/lib64/libwebp.so)
        linux-vdso.so.1 =>  (0x00007fff6c9ff000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe7eb97b000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe7eb75f000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe7eb3d3000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe7ebe62000)

This lead to several DllNotFoundException errors in the log and images were not available when browsing my library. I built version 0.4.1 locally and used this instead and that seemed to work fine.

 

This may or may not be the same issue that people are having in this thread.

 

I don't know if it would be worth including a version built against glibc 2.13 that may be usable more universally.

 

Well the problem is, that there are so many linux distributions with so many different configurations that it is simply not possible to provide pre packaged libraries for all of them.

 

In your case I'd say it would be best if the plugin maintainer adapts his plugin to install the correct version of the dependent libraries automatically and adapts the dllmap eintries for them to point to the system files. Information on what dependencies currently are needed can be found in several threads around here, also we can help with such information if one asks

[Herbie 0]

Well the problem is, that there are so many linux distributions with so many different configurations that it is simply not possible to provide pre packaged libraries for all of them.

 

Thanks for the reply. Yeah, binary compatibility from one linux distro to another can be a bitch ;-) I kind of wonder why linux shared libs are bundled with MB at all rather than just specifying the library/version requirements in the install guide.

 

I wasn't trying to suggest that this is something MB devs need to fix. Just thought the info might be useful to others having the same issue.

[Luke 37054]

we may very well remove them at some point, yea

[Sergio 4]

Well the problem is, that there are so many linux distributions with so many different configurations that it is simply not possible to provide pre packaged libraries for all of them.

 

In your case I'd say it would be best if the plugin maintainer adapts his plugin to install the correct version of the dependent libraries automatically and adapts the dllmap eintries for them to point to the system files. Information on what dependencies currently are needed can be found in several threads around here, also we can help with such information if one asks

 

That library version could not be available in Debian without custom compilation (as Herbie done)

 

The suggestion by Herbie it's the most correct action path. If something has to be universally compatible, it has to require the lowest versions as possible for it's dependencies, not the newest. And of course not integrating them.

 

While making the OMV plugin, I really had a nightmare getting a mono runtime for it to work. Debian didn't had the minimum required version of mono and I was making a custom compilation of it and dealing with libc6.

At the last moment, Mono guys released a repo with a compatible version, so I rapidly incorporated it.

 

All my installs and other partners ones where running well, so I did not expect that libwebp.so issue.

 

Anyways, please start by notify at the OMV-MB3 plugin issue section so I can be aware of any problem that could be my fault and not MB3 staff one.