[Beowulf] GLIBC_3.4.x/GLIBCXX_3.4.x not found on CentOS 7.x?

[Ryan Novosielski]

Hi Beowulfers:

What do you folks use (besides use Singularity or similar) for software that for whatever reason balks because it asks for GLIBC/GLIBCXX 3.4.20 or newer on CentOS 7.x?

From what I’ve read, it’s not safe to build it in an alternate location and use LD_LIBRARY_PATH to have software call it. I am almost certain that this is true of the GLIBC dependencies. I’m less sure of the GLIBCXX dependency. And I know that whenever we build an alternate copy of GCC (like 4.9.x or newer), we create a software module that /does/ in fact place a newer libstdc++.so.6 into the LD_LIBRARY_PATH. What I’ve read /might/ be safe, but problematic in some cases (and no help at all in the case of binary distributions) is using -rpath type stuff at build time. There appears to be a lot of conflicting information out there, and some “just throw a newer libstdc++.so.6 library in a lib directory,” and some “that’s not such a great idea” posts right below them.

Do I misunderstand the situation? Is there a difference between software that demands a newer GLIBC vs. GLIBCXX? Does anyone have a reference one can trust on this subject?

Thanks -- I know there are some really highly qualified people on this list. :-D

--
____
|| \\UTGERS, |---------------------------*O*---------------------------
||_// the State | Ryan Novosielski - ***@rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
|| \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark
`'

[David Mathog]

Post by Ryan Novosielski
What do you folks use (besides use Singularity or similar) for
software that for whatever reason balks because it asks for
GLIBC/GLIBCXX 3.4.20 or newer on CentOS 7.x?

What software would that be?

I frequently run into requirements for more recent versions of the
compilers and other build tools on Centos 6 (or 7). These are typically
resolved using either devtoolset or by upgrading builds of things like
cmake or automake and installing them in /usr/local or my home
directory. Requirements for newer boost versions are distressingly
common, and that is much more of a problem because it is often hard to
coerce the build tools to use it even when one is available. (I'm
looking at YOU cmake.) There is a 1.57 RPM somewhere or other for
Centos, and so far that has always sufficed.

But I don't recall ever needing a newer glibc or glibcxx. Doing that
would be a huge mess unless the code used no other libraries - because
all other common libraries on the system would be linked against the
system version.

Post by Ryan Novosielski
There appears to be a lot of conflicting
information out there, and some “just throw a newer libstdc++.so.6
library in a lib directory,” and some “that’s not such a great idea”
posts right below them.

Safe if no other libraries are involved. See what "ldd" shows. If
there are other libraries, and they have dependencies on the old version
of the newer one you installed, it would be a problem.

Regards,

David Mathog
***@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech
_______________________________________________
Beowulf mailing list, ***@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/l

[Ryan Novosielski]

Post by David Mathog

Post by Ryan Novosielski
What do you folks use (besides use Singularity or similar) for
software that for whatever reason balks because it asks for
GLIBC/GLIBCXX 3.4.20 or newer on CentOS 7.x?

What software would that be?

Where we’ve run into something similar before was the NCI gdc-client. As it happens in this instance, this was a miscommunication. What the user was doing was installing an R package to a copy of R they’d installed with GCC 5.4 which was supplied by a module. When R went to build the additional packages, it eventually ran into this dependency. Our module environment module for GCC 5.4 adds the GCC lib64 directory to the LD_LIBRARY_PATH, as I assumed was how everyone was doing this. I’m now wondering, is this a bad idea/should I be doing something else here?

Post by David Mathog
But I don't recall ever needing a newer glibc or glibcxx. Doing that would be a huge mess unless the code used no other libraries - because all other common libraries on the system would be linked against the system version.

I think the only places one is likely to run into this is by using binaries that come from elsewhere — either Fedora or some other Linux distribution entirely — or when attempting to mix with software built with a newer GCC than the system has.

Post by David Mathog

Post by Ryan Novosielski
There appears to be a lot of conflicting
information out there, and some “just throw a newer libstdc++.so.6
library in a lib directory,” and some “that’s not such a great idea”
posts right below them.

Safe if no other libraries are involved. See what "ldd" shows. If there are other libraries, and they have dependencies on the old version of the newer one you installed, it would be a problem.

I guess one thing I don’t know is how likely it is that software having their libstdc++ library upgraded will actually cause problems. I’d assume that most people will at some point during their job run something that was built against the system libstdc++ library. Yet, I think people compile alternate copies of GCC and provide them all the time. Are they all using -rpath or something similar, or all doing the same not-great-idea thing I’m doing, or
?

--
____
|| \\UTGERS, |---------------------------*O*---------------------------
||_// the State | Ryan Novosielski - ***@rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
|| \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark
`'

[David Mathog]

Post by David Mathog
What software would that be?

Where we’ve run into something similar before was the NCI gdc-client.

#on centos 6.9
cd /tmp
wget
https://gdc.cancer.gov/system/files/authenticated%20user/0/gdc-client_v1.3.0_CentOS7_x64_Beta.zip
unzip gdc-client_v1.3.0_CentOS7_x64_Beta.zip
rm gdc-client_v1.3.0_CentOS7_x64_Beta.zip
ldd gdc-client
linux-vdso.so.1 => (0x00007ffe1d33e000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000313ce00000)
libz.so.1 => /lib64/libz.so.1 (0x000000313d200000)
libc.so.6 => /lib64/libc.so.6 (0x000000313c200000)
/lib64/ld-linux-x86-64.so.2 (0x000000313be00000)
gdc-client -h
./gdc-client: /lib64/libc.so.6: version `GLIBC_2.14' not found (required
by /tmp/_MEIBBRbAt/libz.so.1)

WTF? It unpacks its own libz, and who knows what else, in a
subdirectory of /tmp, and that libz is linked to the wrong glibc
version. Even though the one the binary itself is linked to is the
system libz, which is fine with the system libc. The subdirectory name
changes each time. "strings" shows that gdc-client is full of symbols
starting with "Py". So it is a python based binary of some sort. Leave
it to the US government to come up with something this nutty.
(Although, to be fair, the NCBI uses a different download tool called
"Aspera client" which has none of these issues.)

As it happens in this instance, this was a miscommunication. What the
user was doing was installing an R package to a copy of R they’d
installed with GCC 5.4 which was supplied by a module.

If a different compiler/environment was needed to build some program,
and that program can itself build more programs, then in general it must
be run in the same environment in which it was built. For devtoolset
that would be something like:

scl enable devtoolset-4 'make' # builds "prog"
scl enable devtoolset-4 'prog -args' # builds other things

Regards,

David Mathog
***@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech
_______________________________________________
Beowulf mailing list, ***@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mail