Bug 1163510 - gmsh: error while loading shared libraries: libfreeimage.so.3
Summary: gmsh: error while loading shared libraries: libfreeimage.so.3
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: gmsh
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Sandro Mani
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-11-12 21:45 UTC by Colin Macdonald
Modified: 2014-11-14 10:02 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-11-14 10:02:43 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
gmsh.strace (83.38 KB, text/plain)
2014-11-12 22:30 UTC, Colin Macdonald
no flags Details

Description Colin Macdonald 2014-11-12 21:45:36 UTC
Running gmsh:

$ gmsh
gmsh: error while loading shared libraries: libfreeimage.so.3: cannot open shared object file: No such file or directory

Haven't checked in F21 yet.

Comment 1 Sandro Mani 2014-11-12 22:00:24 UTC
Neither gmsh or libGmsh.so are linked against freeimage:

$ ldd /usr/lib64/libGmsh.so.2.8 | grep freeimage
(nothing returned)
$ ldd /usr/bin/gmsh | grep freeimage
(nothing returned)

Also greeping the source tree for freeimage returns no matches. Do you have some third-party component loaded along with gmsh? Running

$ strace /usr/bin/gmsh

should should show you what is being loaded before the error occurs, so it should give you a hint which is the component causing problems.

In any case, the quick-fix is to just install the freeimage package.

Comment 2 Colin Macdonald 2014-11-12 22:29:54 UTC
For me:

ldd /usr/bin/gmsh | grep libfreeimage
	libfreeimage.so.3 => not found

With "freeimage" package installed:

ldd /usr/bin/gmsh | grep freeimage
	libfreeimage.so.3 => /lib64/libfreeimage.so.3 (0x00007f8607772000)

--------------------------

I do have a libfreeimage left over from some experiments with some third-party (and proprietary?) software:

locate libfreeimage
/usr/lib/plexmediaserver/libfreeimage.so.3

perhaps that is interfering somehow...?

--------------------------

Strace
------

Here's the last of it, I'll sttach the whole thing:

open("/usr/lib64/openmpi/lib/libatlas.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/cbm/.local/lib/libatlas.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/atlas/libatlas.so.3", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0[\5\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=5124904, ...}) = 0
mmap(NULL, 7213136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f7ef60b2000
mprotect(0x7f7ef658a000, 2093056, PROT_NONE) = 0
mmap(0x7f7ef6789000, 40960, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4d7000) = 0x7f7ef6789000
mmap(0x7f7ef6793000, 80, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f7ef6793000
close(3)                                = 0
open("/usr/lib64/openmpi/lib/libfreeimage.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/cbm/.local/lib/libfreeimage.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib64/tls/x86_64/libfreeimage.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/tls/x86_64", 0x7fffe7a372d0) = -1 ENOENT (No such file or directory)
open("/lib64/tls/libfreeimage.so.3", 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/libfreeimage.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/x86_64", 0x7fffe7a372d0)   = -1 ENOENT (No such file or directory)
open("/lib64/libfreeimage.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64", {st_mode=S_IFDIR|0555, st_size=176128, ...}) = 0
open("/usr/lib64/tls/x86_64/libfreeimage.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/tls/x86_64", 0x7fffe7a372d0) = -1 ENOENT (No such file or directory)
open("/usr/lib64/tls/libfreeimage.so.3", 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/libfreeimage.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/x86_64", 0x7fffe7a372d0) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libfreeimage.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64", {st_mode=S_IFDIR|0555, st_size=176128, ...}) = 0
writev(2, [{"gmsh", 4}, {": ", 2}, {"error while loading shared libra"..., 36}, {": ", 2}, {"libfreeimage.so.3", 17}, {": ", 2}, {"cannot open shared object file", 30}, {": ", 2}, {"No such file or directory", 25}, {"\n", 1}], 10gmsh: error while loading shared libraries: libfreeimage.so.3: cannot open shared object file: No such file or directory
) = 121
exit_group(127)                         = ?
+++ exited with 127 +++

Comment 3 Colin Macdonald 2014-11-12 22:30:44 UTC
Created attachment 956882 [details]
gmsh.strace

Comment 4 Colin Macdonald 2014-11-12 22:32:24 UTC
To answer your question, I don't think I have any "third-party component loaded along with gmsh".  Not deliberately anyway.

Comment 5 Sandro Mani 2014-11-12 22:46:52 UTC
There is actually an indirect dependency on freeimage, as can be seen by running lddtree (from pax-utils):
$ lddtree /usr/bin/gmsh
gmsh => /usr/bin/gmsh (interpreter => /lib64/ld-linux-x86-64.so.2)
    [...]
    libngocc.so.0 => /lib64/libngocc.so.0
        libTKSTL.so.9 => /lib64/libTKSTL.so.9
        libTKXDESTEP.so.9 => /lib64/libTKXDESTEP.so.9
            libTKCAF.so.9 => /lib64/libTKCAF.so.9
                libTKCDF.so.9 => /lib64/libTKCDF.so.9
                libTKV3d.so.9 => /lib64/libTKV3d.so.9
                    libTKService.so.9 => /lib64/libTKService.so.9
                        libfreeimage.so.3 => /lib64/libfreeimage.so.3
    [...]

$ repoquery --whatprovides libTKService.so.9
OCE-visualization-0:0.16-1.fc22.x86_64

$ repoquery --requires OCE-visualization | grep freeimage
libfreeimage.so.3
libfreeimage.so.3()(64bit)

So OCE-visualization should pull in freeimage as a dependency.

This is on rawhide. Can you check on F20?

Comment 6 Sandro Mani 2014-11-12 22:49:25 UTC
You might also want to run

$ yum check all

to verify that your rpmdb is in a clean state.

Comment 7 Colin Macdonald 2014-11-12 23:04:21 UTC
"yum check all" seems fine.

On F20:

$ lddtree `which gmsh`
    [...]
    libngocc.so.0 => /lib64/libngocc.so.0
        libTKSTL.so.9 => /lib64/libTKSTL.so.9
        libTKXDESTEP.so.9 => /lib64/libTKXDESTEP.so.9
            libTKCAF.so.9 => /lib64/libTKCAF.so.9
                libTKCDF.so.9 => /lib64/libTKCDF.so.9
                libTKV3d.so.9 => /lib64/libTKV3d.so.9
                    libTKService.so.9 => /lib64/libTKService.so.9
                        libfreeimage.so.3 => not found
    [...]

$ repoquery --requires OCE-visualization | grep freeimage
libfreeimage.so.3
libfreeimage.so.3()(64bit)

And OCE-visualization does not pull in freeimage:

$ yum list OCE-visualization freeimage
Loaded plugins: changelog, langpacks, remove-with-leaves
Installed Packages
OCE-visualization.x86_64             0.16-1.fc20                 @updates
Available Packages
OCE-visualization.i686               0.16-1.fc20                 updates 
freeimage.i686                       3.10.0-16.fc20              fedora  
freeimage.x86_64                     3.10.0-16.fc20              fedora

Comment 8 Sandro Mani 2014-11-12 23:10:10 UTC
OCE-visualization definitely should pull in freeimage:

$ rpm -qp --requires OCE-visualization-0.16-1.fc20.x86_64.rpm  | grep freeimage
libfreeimage.so.3()(64bit)

Unless you have another package which is providing libfreeimage

$ repoquery --whatprovides libfreeimage.so.3
freeimage-0:3.10.0-21.fc22.x86_64

If you run the above, do you get anything else besides freeimage? Perhaps some package installing the /usr/lib/plexmediaserver/libfreeimage.so.3 you mentioned above? In that case, it would be a packaging bug of that package, since libraries in subdirectories should be provided by packages. Otherwise, try reinstalling OCE-visualization.

Comment 9 Sandro Mani 2014-11-12 23:11:04 UTC
typo: [...] since libraries in subdirectories should NOT be provided by packages. [...]

Comment 10 Sandro Mani 2014-11-12 23:37:00 UTC
Additional note: if you installed a rpm which provides libfreeimage locally and not from a repo, repoquery --whatprovides will not show it. Instead, run

$ yum provides libfreeimage.so.3

Comment 11 Colin Macdonald 2014-11-14 10:02:43 UTC
In fact, I needed some raw rpm command (sorry forget exact switches) to see the third-party package (presumably b/c I'd installed a single rpm without a repo).

Anyway, my understanding is this is *not* a bug with gmsh or OCE-visualization, or indeed Fedora, so closing.

Thank you for your help, sorry for the noise.

For the record: third-party stuff (and esp. proprietary third-party) belongs in /opt.  Plex people should do that.


Note You need to log in before you can comment on or make changes to this bug.