Le 05/04/2018 à 20:40, Kevin Klein a écrit :
I want to run Geany on a system running Redhat Enterprise Server 6.7. Many of the dependent libraries are out of date,
That sounds odd. I don't know RHEL, but Geany should require only fairly conservative versions of mostly everything, that I would be surprised to learn are not available with any supported distribution, even older ones. AFAIK we basically only require GTK 2.24 and GLib 2.32, which both predates RHEL 6.7 my a fair margin.
Are you referring to plugins from e.g. the Geany-Plugins repository?
so I built the executable from the same shared directory while logged in to another machine running RHES 7.3 using the “Relocatable GNU/Linux Build” instructions found on this page:
https://wiki.geany.org/howtos/relocatable_build https://wiki.geany.org/howtos/relocatable_build
I also copied all required libraries using the script listed at the bottom of the page. When I try to run Geany on the RHES 6.7 machine, I receive the following error:
As Lex mentioned, this method is marked as unlikely to work just as-is, and there's quite a few reasons why it would not. One of the main ones is that many libraries might have dynamic modules or data files that would not get copied with this technique -- and GTK definitely is one of those.
geany: relocation error: /user/kklein/geany/1.33/bin/../lib/libc.so.6: symbol _dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference
I'm really not sure, but I'd try either to check whether you do have a copy of ld-linux.so that matches your custom build, or better, see if you could avoid using a custom version of libc.so which is a little too much of a core library to play with uncarefully.
What do I need to do to make my relocatable build use the correct version of glibc? Do I just need to install a newer version of glib on the RHES 6.7 machine?
As suggested by others, I would recommend manually building and installing (in a custom directory, like somewhere in your $HOME) newer versions of GTK and/or GLib if that's the issue. This seems like the safest bet, instead of hoping for binary compatibility with a newer release.
Regards, Colomban