Hi,
I’m having an issue similar to this one, where I’m attempting to run Komodo IDE 9.1 on a SLES 11 SP2 machine, but getting this error:
bin/komodo: symbol lookup error: ~tpansino/komodo_9/lib/mozilla/libxul.so: undefined symbol: gdk_window_get_visual
I know that only SP3 and higher is officially supported for SLES11, but are there any known workarounds that could help me out here? Unfortunately I don’t have root access to this machine, so installing additional packages is rather difficult for me to do (not impossible though).
Any and all help would be greatly appreciated. Thanks.
Hey @tapansino91, Other than compiling your own libxul.so that doesn’t need gdk-pixbuf2 (which would require you install a bunch of additional packages…) I’m not aware of a workaround.
Sorry I can’t help further. You’ll need to request to get this package installed on your system. I believe the following command will get you sorted: $ zypper install libgdk_pixbuf-2_0-0
Hey Carey,
Thanks for the response. Darn, I was afraid of that. Is there a way I can check to see if gdk-pixbuf2 is already installed? Like do you know where would one typically find those files on a Linux system? The chances of me convincing someone to install anything on this machine are most likely nil, but if I can find out what directories will be touched as part of the install, it might help me negotiate with my IT dept. Also knowing where it should be might help me figure out if it’s been installed in a non-standard location, in which case I just have to persuade Komodo to look for it in the non-standard place.
Also, one other interesting little tidbit: I can get Komodo IDE 8.5 to work just fine on this same machine, it’s only Komodo IDE 9.* that won’t work. Is there something big that changed under the hood that caused this to break between 8.5 and 9?
Mozilla (what Komodo is built on) was upgraded which is why Komodo 8 works but not Komodo 9. You’ll see similar issues if you Google pixbuf2 and Mozilla I believe.
I’d use a zypper command to see if it’s installed. $ zypper search pixbuf
That will list installed and available packages matching the given search string.
It is an option to use Komodo 8.5 for now until you can get someone to install that needed package.
Hey @careyh, sorry to reactivate the thread, but I think I have some new information regarding this issue I’m having.
I’m a fairly recent college grad with no real experience working with .so files, so when I was talking with a coworker about not being able to run Komodo recently, he suggested I run ldd on the libxul.so. Here’s the result of that:
So I know you suspected my issues had something to do with libgdk_pixbuf-2_0 not being installed, but I do see the .so file located in the ldd output. I’m wondering is it the missing Mozilla stuff that is causing the problem? I know our corporate IT did a sweep recently in which they gutted a whole bunch of Mozilla/Firefox installations from our machines due to security concerns, so I’m wondering if that’s what happened here.
Just as an experiment, I tried locally installing the current firefox and setting my $LD_LIBRARY_PATH to point to that area, but it’s still missing libmozsandbox.so and libmozalloc.so according to the ldd.
Where should I go from here? Can I get a copy of those .so files, or build them somehow? Or do you think that’s not the real issue?
Hi, if your error is still “undefined symbol: gdk_window_get_visual”, then there is one possible cause: your version of GDK is less than 2.24. (libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 is the shared object that contains that symbol.) The question is which package provides that file? On Ubuntu systems, it is libgdk2.0-0:[i386|amd64]. On RHEL/CentOS it appears to be libgdkpixbuf2 or some variant. I don’t know what it is on SLES. When you manage to track down which package owns your /usr/lib64/libgdk-x11-2.0.so.0 file, check the version. If it’s less than 2.24 then you need to upgrade that package.
As @mitchell says above, the missing symbol is from an package lib that is installed on your computer but is NOT from Mozilla. This is a bug in Linux where backwards compatibility was neglected I believe and a function that previously was available is no longer available.
Ok, so the suggestion I’m hearing is to find out what version of the libgdk package is installed, and verify it is greater than 2.24? If not, then I need to compile a later version of that package and try and use the .so files from that?
What about the missing .so files though? How does this help solve that problem? Or will it not matter once I’ve recompiled because they won’t be needed anymore?
I don’t think the output of ldd has anything to do with this issue. The missing symbol is in a native library to the OS.
If someone knows more about what exactly ldd does then please feel free to correct me but I’m assuming that it’s checking for linked binaries that we don’t include because we don’t use them. That doesn’t seem right as we wouldn’t be able to compile then so I’m guessing I’m wrong.
Long story short, I don’t think you need to worry about the missing files reported by ldd. The error we are dealing with is a missing native library function, nothing to do with Mozilla binaries (other than they are using a function that doesn’t exist).
Yes @tapansino91, that is the order of operations.
You may ignore the missing .so. I ran ldd on my working Komodo install and got pretty much the same output and a “missing” .so. I would venture a guess Mozilla is doing something with the LD_LIBRARY_PATH or equivalent at run-time.
@mitchell, @careyh, thanks so much for your help with all of this.
I was able to speak to some members of our IT dept, they confirmed that the version of gdk-pixbuf we had installed was very old (~0.22) and buggy, and that others had experienced the same kinds of missing symbol issues with other IDEs.
The only solution then was to try to do my own build of gdk-pixbuf and go from there, so that’s what I did. To my surprise, I got as far as being able to locally install the package on my machine, and reinstalled Komodo 9 with LD_LIBRARY_PATH set to that path (not sure if that reinstall was necessary, but I figured it couldn’t hurt). This is the output I get now:
So is this the same kind of issue as with gdk-pixbuf? Do I need to now build X11 as well? Because from what I can tell, this seems to be the lastest release of X11, but I could be wrong on that one. Any thoughts?
Hi, sadly it looks like your version of libxrandr2 (or SUSE equivalent) is out of date. I don’t know what the minimum version is that includes the symbol XGetRequest, but it’s very likely you’ll wind up needing to compile X11 and friends if your IT department cannot upgrade the X11 packages. Once again, check which package owns libXrandr.so.2 and see if it needs upgrading.