[Geany-Users] glibc relocation error when trying to run relocatable build
lists.ban at xxxxx
Fri Apr 6 14:23:17 UTC 2018
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:
> 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
> 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.
More information about the Users