Using an older version of glibc?

[Paul Molodowitch]

Hi all - so, I'd like to start following the reference platform (currently aiming for CY2015), but the one bit that's tripping me up at the moment is the glibc maximum version requirement.

I'm using Fedora 19, which comes with gcc-4.8.2, so the gcc requirement is easy; however, the libc version seems to be 2.17.  I see a lot of discussion about linking against older glibc versions, but no clear path forward.  Given that this is now a requirement for the platform, I was hoping someone could at least outline the basic solution - currently, I'm thinking I'm going to have to compile my own libc-2.12, then compile my own gcc-4.8.2 which uses that, then use this custom gcc+glibc to compile my CY2015 projects going forward.  Is this roughly what others are doing? Or is there an easier way?

Thanks,

- Paul

[Francois Chardavoine]

Hi Paul -

A common misconception is that the VFX Reference Platform is meant for studios/facilities, when it is in fact primarily a guideline for software developers (with the bonus side-effect of minimizing the number of versions facilities end up having to deal with). In particular the glibc "highest version allowed" requirement is to ensure that software developers don't link against a newer version than what might be easily available to you, as someone using a distro like Fedora 19. This is why the glibc version has different requirements (max vs min) whether you're a software developer/distributer, or a consumer of 3rd-party software.

In your case (assuming you're not commercializing 3rd party software), using something newer than glibc 2.12 within your facility is perfectly fine (and intended).

Francois.

[Paul Molodowitch]

Regarding glibc - my mistake, I was under the impression that if a software package tried to link against myfunction@GLIBC_2.12, and I made a library that links against myfunction@GLIBC_2.17, that this would cause errors... but I see now that this works fine.

Regarding the reference platform and studios in general: it still affects us indirectly, because we want our compilation platform to match with whatever software we need to integrate with / provide plugins for, to avoid linking errors - not everything provides versioned symbols like glibc.  In an ideal world, we'd compile each component for each plugin to exactly match the dependencies used for each software package; but in practice, for many of the pieces we use "default versions" which get linked against in multiple different places, and it makes sense to use the reference platform to pick those defaults, in the hope that most software vendors start following them.

[Francois Chardavoine]

Yeah, the goal of the VFX Reference Platform is definitely to reduce the matrix of versions of libraries that studios have to deal with. In practice though, even if all software strictly adhered to the platform guidelines, within a studio you always end up having multiple versions of software in play: maybe one show halfway through using maya 2015, and a new show starting on 2016, or perhaps you're using an older version of Nuke on a show at the same time as the latest houdini (based on whatever feature your production may have needed). At the very minimum in that previous-show-to-new-show transition, you always end up needing to build your plugins to link against several versions of libraries to match what the latest 3rd-party software requires.

So while you can always target the VFX Reference Platform guidelines as a starting point within your studio (and use that for "default" versions of libraries), sooner or later you'll need to support multiple simultaneous versions. In your case I would just go with the higher version of the GLIBC which ships with your system.

Francois.

[Mark Streatfield]

As a side note that I think is somewhat relevant here, we make good use of the Upstream Tracker (http://upstream.rosalinux.ru/).  For most common libraries it gives a quite detailed breakdown of the API/ABI compatibility across versions.  glibc compatibility is here http://upstream.rosalinux.ru/versions/glibc.html.  I think you can submit other libraries to be covered, but we've yet to do that.  We use this (primarily with rez) to determine the version range of dependencies a tool should build against and be compatible with.  The greater historical compatibility the broader the range we allow.

In addition, some libraries provide information about their API/ABI compatibility policy.  The one for libstdc++ is very detailed and informative (https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html).  PyQt/Qt has one too, but I can't find it at the moment.  Again, a very useful source of information when deciding what you might stand a chance of being compatible with at build time vs run time.