On 24/01/07, Josef Whiter josef@toxicpanda.com wrote:
Enrico Tröger wrote:
On Wed, 24 Jan 2007 12:26:34 -0500, Josef Whiter josef@toxicpanda.com wrote:
Hi,
Geany doesn't find the vte lib in fedora when you have just the vte package installed, but it works fine when you have vte-devel installed. This is because the normal vte package is something like libvte.so.0.9.4 or something like that, and geany doesn't pick it up,
You had a look at vte.c, so you should know that Geany looks for some so-names as fallback. On Debian, I have the two files libvte.so.4 and libvte.so.4.5.1 where libvte.so.4 is just a symlink to the other one. Why doesn't Fedora does it in that way?
however vte-devel installs libvte.so which geany does pick up, and since i need vte-devel to build the geany package for fedora I didn't
Why do you need the vte-devel package to build Geany? Geany should build independent of the existence of any VTE files, also with enabled VTE support. Just tested with a fresh svn checkout, ran autogen.sh and make. I don't have the vte-dev package installed and all went as expected. The VTE support was compiled in and I could use it.
notice this, but if you don't have vte-devel installed geany complains about not being able to load the terminal. Since I can't require a -devel package for a normal package I have to make geany link vte in during compile instead of doing g_module_open. I just finished this patch this morning and tested it and it works well. Will you guys include this? Or is there a specific reason you use g_module_open and g_module_symbol? It looks like you were putting it
Yes, the reason is to not depend on libvte. The idea was to laod the module if it is found and use it. If it can't be found, just let out the VTE component.
in the configure script at one point, but just commented it out.
Yes, it was a try to detect the lib with the autotools but it is not possible(at least I don't know how) without having installed any dev packages.
I won't apply your patch because I don't want to add the general dependency on libvte. We can add libvte.so.0.9.4 to the list of searched modules. But are you sure that on Fedora there is no symlink to this file without the patch level?
Nick, how it is handled on your system?
Hmm, probably should have asked before doing :). It looks like our vte package does make a link for /usr/lib/libvte.so.9, but for some reason geany was complaining about not being able to find it, even though its in the list of backup modules to look for. I will look into why this isn't behaving properly. Thanks much,
The problem seems to be in vte.c - the if else construct looking for libvte versions will never go past the first check. Works with this patch:
--- vte.c 2007-01-25 10:18:32.000000000 +0000 +++ vte.c.old 2007-01-25 10:18:29.000000000 +0000 @@ -137,8 +137,8 @@ module = g_module_open("libvte.so", G_MODULE_BIND_LAZY); // try to fallback to different versions of libvte.so.x if (module == NULL) module = g_module_open("libvte.so.4", G_MODULE_BIND_LAZY); - if (module == NULL) module = g_module_open("libvte.so.8", G_MODULE_BIND_LAZY); - if (module == NULL) module = g_module_open("libvte.so.9", G_MODULE_BIND_LAZY); + else if (module == NULL) module = g_module_open("libvte.so.8", G_MODULE_BIND_LAZY); + else if (module == NULL) module = g_module_open("libvte.so.9", G_MODULE_BIND_LAZY); }
if (module == NULL)
How about something like this:
const gchar *sonames[] = { "libvte.so", "libvte.so.4","libvte.so.8","libvte.so.9", NULL }; const gchar **modname;
for (module=NULL,modname=sonames; *modname && !module; modname++ ) { module = g_module_open(*modname, G_MODULE_BIND_LAZY); } }
Then it's easy to add more names.
- Jeff