gedit builds but does not launch

[mf2k (Frank Schima)]

I'm trying to run gedit on OS X 10.9.5. It installs fine, but when I go to run it, I see the following error:

$ gedit
Couldn't open /opt/X11/lib/libGL.1.dylib: dlopen(/opt/X11/lib/libGL.1.dylib, 5): image not found

$ port contents mesa | grep libGL
  /opt/local/lib/libGL.1.dylib
  /opt/local/lib/libGL.dylib

$ port installed gedit* mesa
The following ports are currently installed:
  gedit @3.16.1_0+python34 (active)
  gedit-plugins @3.16.0_0+python34 (active)
  mesa @10.5.4_0+osmesa+python27 (active)

[dbevans (David B. Evans)]

Frank, I've been trying for the last few hours but I can't reproduce this result on my Mavericks machine. gedit starts up and runs fine for me.

AFAICT, gedit does not link with any libGL at all. So I'm wondering who it is that is looking for /opt/X11/lib/libGL.1.dylib.

The only candidate I could find was webkit-gtk3 and it links with opt/local/lib/libGL.1.dylib provided by mesa.

Now, I will say that /opt/X11/lib/libGL.1.dylib does exist on my machine: its one of the client libraries provided by XQuartz. I even renamed this lib to something else to see it that would cause gedit to error but it did not. The only apps that I can find that link to it are

/opt/X11/bin/glxgears
/opt/X11/bin/glxinfo

again part of the XQuartz distribution which seems appropriate. (They did error out with same message you got when I renamed /opt/X11/lib/libGL.1.dylib).

So I'm thinking that something on your system related to gedit or its dependencies linked with /opt/X11/lib/libGL.1.dylib instead of the version provided by mesa but I'm at a loss to understand how that happened and who the culprit is.

Questions:

• which X11 server are you using? I'm using XQuartz 2.7.7, not xorg-server{-devel}.
• does /opt/X11/lib/libGL.1.dylib exist on your system?
• have you done any custom configuration on your system (paths, etc) that might get MacPorts confused as to which library to use?
• any other evidence on your end that might help figure this out?

[dbevans (David B. Evans)]

I see you have gedit-plugins installed. Have you tried running gedit with gedit-plugins deactivated? Maybe you have a plugin activated (via Preferences) that I don't? But again not sure which one it might be. Do other GNOME apps such as evince or eog work OK?

[mf2k (Frank Schima)]

To answer your questions from comment:2:

• I'm using xorg-server.

  xorg-server @1.16.4_0 (active)
  

• No
• No
• Nothing unusual going on with my setup that I can think of.

[mf2k (Frank Schima)]

Uninstalling gedit-plugins does not help. Same issue.

[mf2k (Frank Schima)]

I see the same problem with eog:

$ eog
Couldn't open /opt/X11/lib/libGL.1.dylib: dlopen(/opt/X11/lib/libGL.1.dylib, 5): image not found

[dbevans (David B. Evans)]

OK, so you need to find what is linked with /opt/X11/lib/libGL.1.dylib that is causing the failure. Since it doesn't happen for me you'll have to do the leg work here.

Two possible suggestions:

• use otool -L in a shell script to search for ports that link with /opt/X11/lib/libGL.1.dylib. Attached is my modified version (more verbose) of the old depsearch.sh script that might be used.

• run gedit in a debugger (gdb, lldb) to the failure point and see if a back trace will tell you where the error occurred.

[mf2k (Frank Schima)]

When I run it, nothing comes back:

$ sudo ./depsearch.sh '/opt/X11/lib/libGL.1.dylib'
$

[dbevans (David B. Evans)]

Same here, indicating nothing linked to /opt/X11/lib/libGL.1.dylib in the hard coded search paths.

However, if I run

$ depsearch.sh libGL.1.dylib

 mesa (/opt/local/lib/libGL.1.dylib)
 webkit-gtk3 (/opt/local/lib/libwebkitgtk-3.0.0.dylib)

and then

$ otool -L /opt/local/lib/libwebkitgtk-3.0.0.dylib | grep libGL

	/opt/local/lib/libGL.1.dylib (compatibility version 4.0.0, current version 4.0.0)

[neverpanic (Clemens Lang)]

Just to make sure, you don't have DYLD_LIBRARY_PATH set, do you?

[mf2k (Frank Schima)]

Replying to cal@…:

Just to make sure, you don't have DYLD_LIBRARY_PATH set, do you?

No. I do know better. :)

Here is the output for just the library:

$ sudo ./depsearch.sh 'libGL.1.dylib'
 fox (/opt/local/bin/PathFinder)
 fox (/opt/local/bin/adie)
 fox (/opt/local/bin/calculator)
 fox (/opt/local/bin/shutterbug)
 fox (/opt/local/lib/libCHART-1.6.0.dylib)
 fox (/opt/local/lib/libFOX-1.6.0.dylib)
 freeglut (/opt/local/lib/libglut.3.10.0.dylib)
 glw (/opt/local/lib/libGLw.1.dylib)
 gtkglext (/opt/local/lib/libgdkglext-x11-1.0.0.0.0.dylib)
 gtkglext (/opt/local/lib/libgtkglext-x11-1.0.0.0.0.dylib)
 libGLU (/opt/local/lib/libGLU.1.dylib)
 libcaca (/opt/local/bin/cacaclock)
 libcaca (/opt/local/bin/cacademo)
 libcaca (/opt/local/bin/cacafire)
 libcaca (/opt/local/bin/cacaplay)
 libcaca (/opt/local/bin/cacaserver)
 libcaca (/opt/local/bin/cacaview)
 libcaca (/opt/local/bin/img2txt)
 libcaca (/opt/local/lib/libcaca++.0.dylib)
 libcaca (/opt/local/lib/libcaca.0.dylib)
 libquicktime-devel (/opt/local/bin/lqtplay)
 mesa (/opt/local/lib/libGL.1.dylib)
 pcb (/opt/local/bin/pcb)
 webkit-gtk (/opt/local/lib/libwebkitgtk-1.0.0.dylib)
 webkit-gtk3 (/opt/local/lib/libwebkitgtk-3.0.0.dylib)

[mf2k (Frank Schima)]

I completely uninstalled all ports and installed gedit from scratch. Same error. Next I will try to uninstall everything and do a source build of gedit and all the dependencies to see if a binary on the buildbots is the cause.

[mf2k (Frank Schima)]

FYI, a completely fresh source rebuild causes the same problem for me.

[dbevans (David B. Evans)]

Thanks for the update. Odd. I guess I would try running it in a debugger to see if you can get a backtrace that tells you what code produces the load failure if you haven't already.

I'm going out of town tomorrow for the rest of the week but when I return I will try doing a fresh build from scratch as you have done to see if that will reproduce the error.

[wyatt8750@…]

Same problem here with both gedit and eog. It worked fine before I reinstalled it along with everything a few days ago (switched back to X11 from xquartz backend for GTK)

However, I'm running OSX 10.6.8. I am therefore using Apple's X11 and do NOT even have that path (/opt/X11) at all.

Downgrading to previous versions does not help, either.

I have also tried using DYLD_LIBRARY_PATH to make it use one of the other libGL.dylib's on my system, but one fails due to requiring libX11.6.dylib version 10 or later (native's providing 9), and the other one missing the symbol '_gll_noop'.

in case it helps, here's what 'glocate libGL.dylib' returns:

glocate libGL.dylib
/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
/Developer/SDKs/MacOSX10.6.sdk/usr/X11/lib/libGL.dylib
/opt/local/lib/libGL.dylib
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_mesa/mesa/work/destroot/opt/local/lib/libGL.dylib
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
/usr/X11/lib/libGL.dylib

[dbevans (David B. Evans)]

The real issue here is who (which binary) is trying to load /opt/X11/lib/libGL.1.dylib since none of the apps in question should be using it at all.

When gedit crashes with this error, there ought to be a corresponding user (or maybe system?) diagnostic report in Console. If so, this report would show not only the failure to load the library but the name of the binary that references it. Note the name of the report may not be gedit (or whichever app is crashing) so you should look at any report with an appropriate time stamp.

[dbevans (David B. Evans)]

BTW, if you haven't done so already please upgrade to the latest versions of these ports, typically 3.16.2, so we are all working with the same software. Thanks.

[mf2k (Frank Schima)]

Replying to devans@…:

BTW, if you haven't done so already please upgrade to the latest versions of these ports, typically 3.16.2, so we are all working with the same software. Thanks.

I always keep my ports updated to the latest version.

[mf2k (Frank Schima)]

See also #47828

[dbevans (David B. Evans)]

Patch to libepoxy provided by ryandesign in #47828 committed in r136739. This, almost certainly, should fix the issue reported here but please verify that that is the case. Thanks.

[mf2k (Frank Schima)]

Yes, it works now!