Cannot launch banshee: Unhandled Exception: System.DllNotFoundException: libgtk-x11-2.0.so.0

Bug #1191195 reported by Pascal Mons
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
banshee (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

I have the exact same problem as another bug already reported bug which has been marked as invalid.

I strongly disagree with the term Invalid.

When attempting to launch any version [even superseded ones] of banshee [for Precise 12.04 amd64] from the Command Line I get:

$ banshee
[...]
[ERROR] FATAL UNHANDLED EXCEPTION: System.DllNotFoundException: libgtk-x11-2.0.so.0
[...]
[ERROR] FATAL UNHANDLED EXCEPTION: System.DllNotFoundException: libgtk-x11-2.0.so.0

The reported missing library libgtk-x11-2.0.so.0 is part of package libgtk2.0-0 (I have as well libgtk2.0-0:i386 installed) and is located at the right place. i.e.

$ locate libgtk-x11-2.0.so.0
/usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
/usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10
/usr/lib/vmware/lib/libgtk-x11-2.0.so.0
/usr/lib/vmware/lib/libgtk-x11-2.0.so.0/libgtk-x11-2.0.so.0
/usr/lib/vmware-installer/2.1.0/lib/lib/libgtk-x11-2.0.so.0
/usr/lib/vmware-installer/2.1.0/lib/lib/libgtk-x11-2.0.so.0/libgtk-x11-2.0.so.0
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.10
$

The logs from strace and MONO_LOG_LEVEL are similar the earlier reported bug

$ strace -e trace=open banshee 2>&1 | grep libgtk-x11-2.0.so.0\"

$ MONO_LOG_LEVEL=debug banshee

What is amazing in the MONO_LOG_LEVEL is the reporting of fictuous libraries not found i.e.

/usr/lib/mono/4.0/mscorlib.dll.so: cannot open shared object file: No such file or directory

Well have the .dll file (which is a Windows library extension type). I have never seen before a .dll.so (mixture of Windows and Linux library ?).

Anyway I did have OpenGL installed and as well mesa (libgl1-mesa* packages).

My Ubuntu 12.04 is properly functioning and obviously I have a lot of application installed. Of all the sound player installed only Banshee is unable to launch ...

There is obviouly something wrong with this application.

I am ready to provide further information upon request.

In the mean time I will remove this application to avoid being annoyed by non functional updates from Ubuntu Updates required now a partial upgrade ...

Revision history for this message
Pascal Mons (anton+) wrote :
Revision history for this message
Pascal Mons (anton+) wrote :

The previously reported bug marked later as Invalid was :

https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/717850

Revision history for this message
Chow Loong Jin (hyperair) wrote :

Could I have the full output of the invocation with MONO_LOG_LEVEL please? It looks like it isn't present in the attachment.

Changed in banshee (Ubuntu):
status: New → Incomplete
Revision history for this message
Pascal Mons (anton+) wrote :

Thank you for your quick answer. Yes I did not attach the MONO_LOG_LEVEL log, here it is.

Well the Ubuntu Updates for Partial upgrade was not related to Banshee but to a wine 1.6 rc1 and today rc2 which sports 2 same binaries (executable files in /usr/bin/) in 2 different packages ... coming someone at ubuntu.com in L.A. ...

Revision history for this message
Chow Loong Jin (hyperair) wrote : Re: [Bug 1191195] Re: Cannot launch banshee: Unhandled Exception: System.DllNotFoundException: libgtk-x11-2.0.so.0

On Sat, Jun 15, 2013 at 12:54:33PM -0000, Antonio19 wrote:
> Thank you for your quick answer. Yes I did not attach the MONO_LOG_LEVEL
> log, here it is.

Judging from the following line...

| Mono: DllImport error loading library: '/usr/lib/libpng12.so.0: version `PNG12_0' not found (required by /usr/lib/x86_64-linux-gnu/libcairo.so.2)'.

It looks like you've got a broken libpng12.so.0? What does
"ldd /usr/lib/x86_64-linux-gnu/libcairo.so.2" say?

--
Kind regards,
Loong Jin

Revision history for this message
Chow Loong Jin (hyperair) wrote :

On Sun, Jun 16, 2013 at 12:48:43AM +0800, Chow Loong Jin wrote:
> On Sat, Jun 15, 2013 at 12:54:33PM -0000, Antonio19 wrote:
> > Thank you for your quick answer. Yes I did not attach the MONO_LOG_LEVEL
> > log, here it is.
>
> Judging from the following line...
>
> | Mono: DllImport error loading library: '/usr/lib/libpng12.so.0: version `PNG12_0' not found (required by /usr/lib/x86_64-linux-gnu/libcairo.so.2)'.
>
> It looks like you've got a broken libpng12.so.0? What does
> "ldd /usr/lib/x86_64-linux-gnu/libcairo.so.2" say?

Actually, looking at the libpng12-0 package, libpng12.so.0 should reside in
/usr/lib/x86_64-linux-gnu/libpng12.so.0 rather than in /usr/lib/.

It looks like you have a stale libpng12.so.0 library there breaking things.

--
Kind regards,
Loong Jin

Revision history for this message
Pascal Mons (anton+) wrote :

This is the result libked libraries in libcairo2

$ ldd /usr/lib/x86_64-linux-gnu/libcairo.so.2
linux-vdso.so.1 => (0x00007fffa47ff000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2fb0515000)
libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f2fb027e000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f2fb0043000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f2fafd8a000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f2fafb62000)
libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f2faf95e000)
libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f2faf754000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f2faf536000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f2faf32b000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f2faeff6000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f2faede5000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2faebcd000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f2fae9c5000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2fae6c0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2fae2f7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2fb0a7a000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f2fae0cd000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f2fadec9000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f2fadcc3000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2fadabf000)
$

Well I have in principle the Ubuntu package for libpng12 installed at the right place. I didn't modify it.
However, I installed he latest version libpng 1.62 whih I compiled. I have ImageMagick, wxWidgets and WxPython working with libpng1.62

Till now I didn't had any application not working with this set-up. I have a lot of Photo Video applications and the latest versions can compile with libpng1.62. However it looks like Ubuntu officials apps are locked in at libpng1.2 ...

However I did try to compile libcairo ad i is still not working at all with libpng1.62 (I mean libpng >= 1.15).

libpng.org on their website still have the remainder for making the code compatible.

Portability Note
----------------------
The libpng 1.5.x and 1.6.x series continue the evolution of the libpng API, finally hiding the contents of the venerable and hoary png_struct and png_info data structures inside private (i.e., non-installed) header files. Instead of direct struct-access, applications should be using the various png_get_xxx() and png_set_xxx() accessor functions, which have existed for almost as long as libpng itself.

If your application is fully dependent on libcairo that may explain the behaviour.

Anyway I have left he libpng1.2 libraries at their original place.

Revision history for this message
Chow Loong Jin (hyperair) wrote :

On Sun, Jun 16, 2013 at 01:12:48AM -0000, Antonio19 wrote:
> This is the result libked libraries in libcairo2
>
> $ ldd /usr/lib/x86_64-linux-gnu/libcairo.so.2
> linux-vdso.so.1 => (0x00007fffa47ff000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2fb0515000)
> libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f2fb027e000)
> libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f2fb0043000)
> libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f2fafd8a000)
> libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f2fafb62000)
> libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f2faf95e000)
> libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f2faf754000)
> libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f2faf536000)
> libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f2faf32b000)
> libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f2faeff6000)
> libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f2faede5000)
> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2faebcd000)
> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f2fae9c5000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2fae6c0000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2fae2f7000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f2fb0a7a000)
> libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f2fae0cd000)
> libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f2fadec9000)
> libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f2fadcc3000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2fadabf000)
> $

Okay, that's kinda odd, ldd seems to resolve libpng12.so.0 to the system one
present at /lib/x86_64-linux-gnu/libpng12.so.0, but mono seems to load the other
one.

> Well I have in principle the Ubuntu package for libpng12 installed at the right place. I didn't modify it.

This really doesn't matter -- adding a library with the same name into one of
the system libdirs will alter the library resolution when attempting to load the
said library.

Could you run "sudo ldconfig -v" and give me the output please?

--
Kind regards,
Loong Jin

Revision history for this message
Adam Conrad (adconrad) wrote :

This is not a bug in Ubuntu. If you put a library on the system library directories, you need to expect that it will be used in linker resolution. There's no way to magically have half your applications look at one, and the other half another, since linking is done by raw SONAME, not full path.

If you need to install a different version of system libraries that lack symbols, you should probably have them off the ldconfig path entirely, in the same directory as your application, or use LD_* hacks to hint to your application where to find them, or compile with rpaths directly to your library.

Changed in banshee (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
Pascal Mons (anton+) wrote :
Download full text (4.7 KiB)

Trouble is that these libraries have different names and are all present. It should be to the applications to decide whatever library they want to use and the system shoud not interfere in any way. Albeit it looks like there is some weird interferences for some applications. The new libpng libraries don't lack any functional things as I would say the 1.2 are old freezed version receiving only security updates. The matter is that png_struct and png_info data are no more in header files (for devel) and that the source code of applications has to be adapted to this reality using png_get_xxx() and png_set_xxx() accessor functions. Some applications developpers refused to do and locked down the libnpg shared library to the 1.12 version.

Here is the result of

$ sudo ldconfig -v > ldconfig-v.log

attached. Both libpng libraries are visible in the log.

Here is a summary of what I have done about libpng in my system.
------------------------------------------------------------------------------------------
I have set the libpng16 in /usr/lib/ (this is the default from compiling the tarball) and made sym links to /usr/lib/x86_64-linux-gnu

Compiled package libpng16-0_1.6.2-0ubuntu0_amd64.deb
------------------------------------------------------
Installed Files
---------------
/usr/bin/libpng-config ---> symbolic link to libpng16-config
/usr/bin/libpng16-config
+/usr/include/libpng ---> symbolic link to libpng16
/usr/include/libpng16
/usr/include/libpng16/png.h
/usr/include/libpng16/pngconf.h
/usr/include/libpng16/pnglibconf.h
/usr/include/png.h ---> symbolic link to libpng16/png.h
/usr/include/pngconf.h ---> symbolic link to libpng16/pngconf.h
/usr/include/pnglibconf.h ---> symbolic link to libpng16/pnglibconf.h
/usr/lib/libpng.a ---> symbolic link to libpng16.a
/usr/lib/libpng.la
/usr/lib/libpng.so ---> symbolic link to libpng16.so
/usr/lib/libpng16.a
/usr/lib/libpng16.la
/usr/lib/libpng16.so ---> symbolic link to libpng16.so.16.2.0
/usr/lib/libpng16.so.16 ---> symbolic link to libpng16.so.16.2.0
/usr/lib/libpng16.so.16.2.0
/usr/lib/pkgconfig
/usr/lib/pkgconfig/libpng.pc ---> symbolic link to libpng16.pc
/usr/lib/pkgconfig/libpng16.pc
/usr/share/man/man3
/usr/share/man/man3/libpng.3.gz
/usr/share/man/man3/libpngpf.3.gz
/usr/share/man/man5
/usr/share/man/man5/png.5.gz

I did add a symbolic link named libpng12.so.0 ---> libpng.so
----------------------------------------------------------------
$ cd /usr/lib/
$ sudo ln -s libpng.so libpng12.so.0

Package libpng12-0 (Official Ubuntu)
------------------------------------
libpng12-0 1.2.46-3ubuntu4 PNG library - runtime

Installed Files
---------------
/lib/x86_64-linux-gnu/libpng12.so.0 ---> symbolic link to libpng12.so.0.46.0
/lib/x86_64-linux-gnu/libpng12.so.0.46.0
/usr/share/doc-base/libpng12
/usr/share/doc/libpng12-0
/usr/share/doc/libpng12-0/ANNOUNCE
/usr/share/doc/libpng12-0/KNOWNBUG
/usr/share/doc/libpng12-0/README.Debian
/usr/share/doc/libpng12-0/README.gz
/usr/share/doc/libpng12-0/TODO
/usr/share/doc/libpng12-0/changelog.Debian.gz
/usr/share/doc/libpng12-0/copyright
/usr/share/doc/libpng12-0/libpng-1.2.46.txt.gz

Pacakge libpng12-dev (Official Ubuntu)
------------------...

Read more...

Revision history for this message
Pascal Mons (anton+) wrote :

Well after posting the explanation of what I have done about libpng12 and libpng16 and reading from Chow Loong Jin (hyperair) that his analysys of MONO points him to :

Mono: DllImport error loading library: '/usr/lib/libpng12.so.0: version `PNG12_0' not found

I tried to remove the symbolic link I did add manually :

$ sudo rm /usr/lib/libpng12.so.0

The program looks at the first instance of the library found (may be). So now it has to go at the right place to find it in /lib/x86_64-linux-gnu

And it looks like now Banshee 2.4.1 is working fine :-). Then I just performed an Ubuntu Update (Gnome) since I am a subscriber of the ppa maintained by Chow Loong Jin (hyperair) and the last version 2.6.1 of Banshee is now working in my system.

Thank you so much Mr. Chow Loong Jin (hyperair) for your time and insight.

I will later try to compile and build a package on my system using the libpng16 libraries.

Can you you please update the status of this bug to Fixed instead of Invalid ? Thanks.

One day I hope Ubuntu will try to move on from libpng12 which is on old version receiving only security updates. One day thre will be no support at all for it.

Revision history for this message
Chow Loong Jin (hyperair) wrote :

On Sun, Jun 16, 2013 at 12:37:13PM -0000, Antonio19 wrote:
> [...]
> Can you you please update the status of this bug to Fixed instead of
> Invalid ? Thanks.

No. We don't support cases where you install random libraries into system
locations and break your system. Therefore your bug is invalid, and not relevant
to Ubuntu.

On a side note, I believe you have a very mistaken view of how Linux library
resolution works, and would suggest that you read up further before you break
your system any more than it already is.

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html seems like a
good point to start.

--
Kind regards,
Loong Jin

Revision history for this message
Pascal Mons (anton+) wrote :

Eveything is working fine in my system and I don't consider it "broken".

My point of view is that Ubuntu is sticking with its "system build" to antique version of libraries. I obviously don't know the full reason why? This should in part comes from some developper / packager whom chose to ignore the natural evolution of software which is part of the so called "Ubuntu system build".

Eventually there will be no more security fixes for libpng12 from its deleloppers @ http://www.libpng.org/pub/png/libpng.html.

Linux is a free OS is not owned by Utuntu or other distribution.

When I have time I will look-up your information in order to build my own packages when needed.

Revision history for this message
Adam Conrad (adconrad) wrote :

There's nothing wrong with installing a library with a different SOVER (as you did), there's everything wrong with then linking the old SOVER to the new one. That was (as you discovered) your only mistake here. It's perfectly fine to have multiple versions installed.

Debian and Ubuntu will move to libpng 1.6.x at some point, probably, but we're in no rush to port the entire world either.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.