glibc, PI 1.8

[kuki]

hey guys, I'm new here and I'm using ubuntu LTS 12.04 on my PC and SL6 (RHEL6) on my notebook. 1.7 on RHEL6 works fine, 1.8 does not. It keeps complaining about missing glibc libraries which obviously do not exist (glibc 2.12). According to the system specs you support RHEL6, can anyone gimme a hint how to get it working without upgrading the glibcs ? Thanks!

EDIT: This is a real showstopper, plz compile it for RHEL6 as well, not only deb. SL is used in many universities. It is the main OS.

[georg.viehoever]

I agree, RHEL6/CentOs are very popular in commercial/university environments. It makes sense to see them as a valid baseline for the more stable Linux variants.
Georg

[kuki]

Ok never mind, I'll just use 1.7 instead. Its somewhat misleading that RHEL6 is supposed to work  (http://pixinsight.com/sysreq/index.html) but the latest PI version doesn't. Perhaps in the future it will who knows. I sent an email to the pixinsight support as well asking if RHEL compatibility in general is gonna be dropped in future releases, never got an answer so far. Anyway, better having PI working on a limited amount of distros than on none at all :-)

[Juan Conejero]

Hi,

I am sorry for this problem. Unfortunately, right now PI 1.8 requires glibc version 2.15 (March 2012). I have tried hard to force linkage against glibc 2.12 (May 2010), which is the version in RHEL 6, but I have failed (see for example this post on stackoverflow.com to see how this can be done). PI is too complex to force all the required symbols to link with a specific glibc version across all executables and shared libraries; it is a real nightmare.

Currently we are using Fedora 16 as our main development platform. PI 1.7 was developed on Fedora 14. The only solution is installing a virtual machine with Fedora 14 and rebuild the entire platform on that machine. However, this is really time-consuming, and we can't face this task now (a lot of manual work is required to set up a development machine to build PI, and we haven't automated this task). Our absolute priority is now releasing a fully stable RC2, and then the final 1.8.0 release.

As far as I know, glibc cannot be updated on a Linux system (if somebody knows how, I am all ears). The best solution from the user side is installing a newer distribution. For example, the just-released Fedora 18 with KDE is probably the best platform to run PixInsight.

[kuki]

Hi Juan!
Thanks for the insight. Basically the glibc can be upgraded, I did it *once* and never again on a SLES 8, but its really messy and against the doctrine of any enterprise linux distro, I mean the whole point of an EL is to have a common stable and longtime supported base that works with specialised 3rd party software without breaking things, contrary to short-intervaled enduser/desktop distros that loose support if not upgraded quite quickly. Sorry to say that but fedora, although being the beta-testing platform of RHEL (as is opensuse for SLES), belongs to latter category IMHO :-( Anyway as posted before I'm happy with 1.7 as well, even if not upgradable. I propose you remove the RHEL6 as supported from the system requirements page or do a simple matrix glibc/PI-version, that would help getting the right PI version (or the right distro :-)

Ciao!

[georg.viehoever]

...As far as I know, glibc cannot be updated on a Linux system (if somebody knows how, I am all ears). The best solution from the user side is installing a newer distribution. For example, the just-released Fedora 18 with KDE is probably the best platform to run PixInsight.

I think you are right about glibc. I have run into this problem again and again, and the only solution seems to be to recompile everything on the baseline platform (e.g. RHEL6). In most cases, the software then also runs on newer Linuxes.

Regarding Fedora18: I would recommend to wait 1-3 months. The first version of any Fedora release usually have quirks...
Georg

[kuki]

I was somewhat reluctant saying that as a 'newbie', but Georg seems to understand my point: Compile on an EL (even RHEL 5?) since binaries are afaik backwards compatible. Drop fedora (15,16,17,18..., u kidding me?) as dev platform as it has a way too high release cadence. Focus your QA on some major distros like ubuntu LTS and the latest ELs, y hasta, todo cojonudo!