So, you thought that you have failed compiling Tulip on MacOS X? The plugins can’t get loaded? Can’t find the
Look again! Check files inside the
lib directory. Let me show you mine.
[email protected] ~/apps/tulip-3.1.0/lib $ file * libtulip: symbolic link to `libtulip-3.1' libtulip-3.1: Mach-O dynamically linked shared library i386 libtulip-ogl: symbolic link to `libtulip-ogl-3.1' libtulip-ogl-3.1: Mach-O dynamically linked shared library i386 libtulip-ogl.la: ASCII English text libtulip-pluginsmanager: symbolic link to `libtulip-pluginsmanager-3.1' libtulip-pluginsmanager-3.1: Mach-O dynamically linked shared library i386 libtulip-pluginsmanager.la: ASCII English text, with very long lines libtulip-qt4: symbolic link to `libtulip-qt4-3.1' libtulip-qt4-3.1: Mach-O dynamically linked shared library i386 libtulip-qt4.la: ASCII English text, with very long lines libtulip.la: ASCII English text tlp: directory
Files that have “Mach-O dynamically linked shared library i386” as their description are surely interesting. Why don’t they have a
.dylib extension? You can find a similar “phenomenon” inside the
tlp directory which contains Tulip plugins. Where is the extension gone?
Since Tulip checks for
.dylib extension on MacOS X, it would not be able to load the plugins. Because they are simply not there. No files with that extension. The application loads very fast since no plugins found. And you also can’t do much since Tulip is (probably) nothing without plugins.
I don’t know why the configuration scripts or the compiler or the linker or whatever it is don’t create shared libraries with
.dylib extension. But as a workaround, I found a simple solution to make Tulip recognize the libraries. Just by simply adding the extension!
One simple command and all is done.
$ ls *-3.1 *-3.1.0 | while read file; do ln -s $file $file.dylib; done
Run that inside the
lib/tlp/view directories. Maybe inside
lib/tlp/designer too. Don’t worry when it tells “No such file or directory”.
And.. now you have it.