libasan in SL7

Daniel Feenberg

unread,

Dec 5, 2018, 6:39:22 PM12/5/18

to

We have updated our OS to Scientific Linux 7 (same as Centos 7 or RH 7) and find that the sanitize-address function of gfortran no longer works, because libasan is not available. Several posting confirm that libasan must be installed as a separate operation. I run "yum install libasan" and am told it is installed and I can check that it is in a directory in the LD_LIBRARY_PATH. What else could be wrong? I see posting that imply I should install libasan0 instead, but yum doesn't know about that library. This used to work in SL6, or least almost work (it usually complained about address overlap).

The message is: /usr/bin/ld: cannot find -lasan

Daniel Feenberg
NBER

Themos Tsikas

unread,

Dec 6, 2018, 6:04:34 AM12/6/18

to

Hello,

You probably need to install the development library, is it in package "libasan-static"?

Themos

Ev. Drikos

unread,

Dec 6, 2018, 10:52:46 AM12/6/18

to

On 06/12/2018 1:39 AM, Daniel Feenberg wrote:
> We have updated our OS to Scientific Linux 7 (same as Centos 7 or RH 7) and find that the sanitize-address function of gfortran no longer works, because libasan is not available. Several posting confirm that libasan must be installed as a separate operation. I run "yum install libasan" and am told it is installed and I can check that it is in a directory in the LD_LIBRARY_PATH. What else could be wrong? I see posting that imply I should install libasan0 instead, but yum doesn't know about that library. This used to work in SL6, or least almost work (it usually complained about address overlap).
>
> The message is: /usr/bin/ld: cannot find -lasan

I haven't faced the particular problem. Below there is a short list with
the package names (ie rpm -qa libasan), file names and installation
directories of the ASAN library (per compiler) in a RHEL 7.4 system,
where the ASAN libraries seem to be functional in all installations.

A) System compiler:
$ cd /usr/lib64
$ rpm -qf libasan.so.0
libasan-4.8.5-16.el7.x86_64
$ cd /usr/lib
$ ls libas* | grep asan
$

There is also a static version: libasan-static-4.8.5-16.el7.x86_64

B) Custom installation of gcc 4.8
(by my custom installation script at https://github.com/drikosev/pc)
$ cd /usr/local/lib
$ rpm -qf libasan.so.0
gcc-4.8-5.x86_64
$ cd /usr/local/lib64
$ rpm -qf libasan.so.0
gcc-4.8-5.x86_64

C) Custom installation of gcc 7 & 8
$ cd /opt/local/lib
$ rpm -qf libasan.so.4
gcc7-7.1-0.x86_64
gcc7-7.3-0.x86_64
$ rpm -qf libasan.so.5
gcc8-8.1-0.x86_64
cd /opt/local/lib64
$ rpm -qf libasan.so.4
gcc7-7.1-0.x86_64
gcc7-7.3-0.x86_64
$ rpm -qf libasan.so.5
gcc8-8.1-0.x86_64

$ echo ${LD_LIBRARY_PATH}
/opt/local/lib64

Regards,
Ev. Drikos

Daniel Feenberg

unread,

Dec 6, 2018, 11:33:19 AM12/6/18

to

On Thursday, December 6, 2018 at 6:04:34 AM UTC-5, Themos Tsikas wrote:
> Hello,
>
> You probably need to install the development library, is it in package "libasan-static"?
>
> Themos
>

That works, if followed by "yum clean all" to get the program to link. But any attempt to execute the a.out file results is a message from the address sanitizer:

Shadow memory range interleaves with an existing memory mapping. ASan
cannot proceed correctly. ABORTING.

which is apparently a Linux kernel bug not fixed until version 4.12.8-2. SL7 is still at 3.10.0-862. See

https://github.com/google/sanitizers/issues/856

for details. There is a workaround posted there:

setarch x86_64 -R ./a.out

but after modifying a.out with that any attempt to execute gave the message:

Error loading HSL dynamic library libhsl.so: libhsl.so: cannot open
shared object file: No such file or directory

which is a bit surprising, since I haven't had any trouble loading it before on the unmodified a.out.

It is a bit frustrating that important tools are so far ahead of the packages. I wonder if there are philosophical differences among developers that keep the packages so out of date, or just inertia?

Daniel Feenberg
NBER

Juergen Reuter

unread,

Dec 7, 2018, 10:55:19 AM12/7/18

to

Well SL7 is already out-of-date even from their side, as SL8 is out very
soon. SL7 is a very conservative system that guarantees stability over a
long period of time, but it is usually very outdated. Note that the gcc
version of that system is 4.8.5 which is hilariously old.

--
Juergen Reuter
Theoretical Particle Physics
Deutsches Elektronen-Synchrotron
Hamburg, Germany
------------------------------------
invalid is desy .and. com is de

Daniel Feenberg

unread,

Dec 9, 2018, 10:32:21 AM12/9/18

to

On Friday, December 7, 2018 at 10:55:19 AM UTC-5, Juergen Reuter wrote:
> Well SL7 is already out-of-date even from their side, as SL8 is out very
> soon. SL7 is a very conservative system that guarantees stability over a
> long period of time, but it is usually very outdated. Note that the gcc
> version of that system is 4.8.5 which is hilariously old.
>

Where did you find information about SL8? Will it have a recent gcc? We have found it disccouraging that many packages (such as R) require a more recent gcc than any OS we know of wants to use. Mucking about with libraries is very time-consuming.

Daniel Feenberg

spectrum

unread,

Dec 9, 2018, 7:48:33 PM12/9/18

to

> Where did you find information about SL8? Will it have a recent gcc?

I've searched the net for RHEL8, and it seems the beta testing is already available...

Introducing Red Hat Enterprise Linux 8 Beta
https://www.redhat.com/en/blog/powering-its-future-while-preserving-present-introducing-red-hat-enterprise-linux-8-beta?intcmp=701f2000001Cz6OAAS

Get RHEL 8 Beta
https://developers.redhat.com/rhel8/getrhel8/

but I couldn't find the information about the version of GCC etc.
(This blog says that python3.6 will be the default, and "application stream"
will be introduced to keep apps up-to date (?))
https://www.certdepot.net/rhel8/

Juergen Reuter

unread,

Dec 10, 2018, 9:38:53 AM12/10/18

to

Here is the reference:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-beta/html/8.0_beta_release_notes/new-features#compilers_and_development_tools_2

So, it seems it comes with gcc 8.2, which for me looks like a tremendous
jump from 4.8.5 -> 8.2 from RHEL 7 to RHEL 8 (resp. CentOS or Scientifix
Linux)

Message has been deleted

spectrum

unread,

Sep 28, 2019, 10:11:23 AM9/28/19

to

CentOS-8 and CentOS Stream have been released this week, and it seems GCC-8.2 is used.
(There seems to be some caveat about python 2 vs 3, so be careful...)

https://lists.centos.org/pipermail/centos-announce/2019-September/023449.html
https://www.redhat.com/en/blog/transforming-development-experience-within-centos
https://www.zdnet.com/article/red-hats-centos-8-arrives-heres-what-you-get-with-it/

Installation notes etc are here:
https://wiki.centos.org/Manuals/ReleaseNotes/CentOS8.1905?action=show&redirect=Manuals%2FReleaseNotes%2FCentOSLinux8
https://wiki.centos.org/Manuals/ReleaseNotes/CentOSStream