experchange > fortran

Daniel Feenberg (12-06-18, 01:39 AM)
We have updated our OS to Scientific Linux 7 (same as Centos 7 or RH 7) andfind 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 (12-06-18, 01:04 PM)
Hello,

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

Themos

On Wednesday, 5 December 2018 23:39:22 UTC, Daniel Feenberg wrote:
[..]
Ev. Drikos (12-06-18, 05:52 PM)
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 )
$ 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 (12-06-18, 06:33 PM)
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



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 (12-07-18, 05:55 PM)
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.

On 12/6/18 17:33, Daniel Feenberg wrote:
[..]
Daniel Feenberg (12-09-18, 05:32 PM)
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 (12-10-18, 02:48 AM)
> 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


Get RHEL 8 Beta


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 (?))
Juergen Reuter (12-10-18, 04:38 PM)
On 12/10/18 01:48, spectrum wrote:
> I've searched the net for RHEL8, and it seems the beta testing is already available...
> Introducing Red Hat Enterprise Linux 8 Beta
>
> Get RHEL 8 Beta
>
> 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 (?))
>


Here is the reference:


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)