How To Downgrade Gtk2 Libs In CentOS 6.8?

Home » CentOS » How To Downgrade Gtk2 Libs In CentOS 6.8?
CentOS 7 Comments

Hi all. I’m using a CentOS 6.8 VM to do volunteer builds for an open source project. I want to build Pale Moon with a gtk2 library older than 2.24, to allow people with older linuxes to run it. Short summary, if built against version gtk2-2.24 and/or higher, the binary will use a function that does not exist in gtk2-2.23 and lower. Net result is that the program dies with an “undefined symbol:” error for people with machines lower than gtk2-2.24. Yes, before you ask, they do get security fixes backported.

The hits from my Google search suggested…

yum downgrade gtk2

The response from yum was…

Only Upgrade available on package: gtk-2.24.23-8.e16.i686
Nothing to do

Are there ways around this?

7 thoughts on - How To Downgrade Gtk2 Libs In CentOS 6.8?

  • Walter Dnes wrote:

    One way would be to do the build on the same OS as the ‘older linux’ ?

    However, CentOS 6.5 shipped with gtk2-2.20.1-4.el6, CentOS 6.6 and above shipped with gtk-2.24 – see http://vault.CentOS.org/6.5/os/

    You _might_ be able to downgrade gtk-2 to that shipped with CentOS 6.5 –
    but I guess there may be a myriad of dependencies on gtk-2.24 that prevent this on a CentOS 6.8 install …

    Otherwise, use a CentOS 6.5 VM to do the build (with the usual caveats that 6.5 is old/out-of-date/etc)?

    James Pearson

  • I suggest building the software using mock chroots, built against older versions of CentOS. You can set up custom chroots in /etc/mock/.

    For example, I have staged versions of CentOS7 (with staged yum repos) that I use to build kernel modules, so I can build the latest version of OpenAFS against kernels other than the latest, since our environment’s kernels don’t get updated immediately but I will still need to have OpenAFS kmods. You could do something similar, only pointing the yum repos at vault.CentOS.org <http://vault.CentOS.org/> repos.


    Jonathan Billings

  • This ^^ (use mock).

    You can use mock chroots in sandbox mode to manually get whatever install you want, or if all the things you want are in (for example)
    CentOS 6.5, you can point your config files for mock to use 6.5 repo from http://vault.CentOS.org/ and build against that.

  • [snip]
    The OP noted the target environment has security fixes backported. Is the same true of a mock environment built from vault.CentOS.org?
    If not, could a binary built under mock introduce old flaws?

    jl

  • Jon LaBadie wrote:

    At run time, the application will use whatever shared libs exist on the target platform – not those from the build platform, so I’m guessing, as long as the target OS has security fixes back ported, then it will be OK …

    James Pearson

  • Well, I have no idea what the control is for the OS they are using. Ideally, all the modifications made to that OS were done via RPMs that are in a separate repository .. and that separate repository is being maintained where reproducible installs can be done. If that is the case, then he can build all software against that controlled repository.

    Of course, if someone builds against an older repo, like CentOS-6.5, that will entail potential security issues. That is usually WHY
    packages have been upgraded. So, in general, the OP is likely already at risk with security issues. If you want to go outside the bounds of what CentOS provides, you will have to do a whole lot of work to maintain security.

    And the package he wants to use (gtk2-23 or less) is not going to run on an up2date CentOS system as everything gtk will have been built to work with the latest version and will likely NOT run with the older version. That would likely be all gnome based things.

    So, I would recommend that they rebuild their software to use CentOS-6.8
    and use that as the base of their environment.

    But what is not likely to happen is a very much lower version of gtk2 in any CentOS version.

    Thanks, Johnny Hughes