View Issue Details

IDProjectCategoryView StatusLast Update
0015241CentOS-7compat-libgfortranpublic2018-09-07 16:23
Status newResolutionopen 
Product Version7.5.1804 
Target VersionFixed in Version 
Summary0015241: missing libquadmath linkage in compat-libgfortran-41-4.1.2-44
DescriptionImporting a DSO ( from the numpy 1.7.1 python package (with Atlas 3.8.4) on an earlier CentOS5 or CentOS6 fails on CentOS7 with:

$ env LD_LIBRARY_PATH=/software/python/2.6.4/linux.centos6.x86_64/lib /usr/bin/python -c 'import lapack_lite'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: /lib64/ undefined symbol: sqrtq

The compat-libgfortran-41-4.1.2-44 library providing does not link against (the DSO providing the <func>q named symbols):

$ nm -D /lib64/ | grep sqrtq
                 U csqrtq
                 U sqrtq
$ objdump -p /lib64/ | grep NEEDED

$ ldd /lib64/ => (0x00007ffc5b1cf000) => /lib64/ (0x00007fdd39c9e000) => /lib64/ (0x00007fdd398d1000)
        /lib64/ (0x00007fdd3a289000)

LD_PRELOAD makes it work:
$ env LD_PRELOAD=/usr/lib64/ LD_LIBRARY_PATH=/software/python/2.6.4/linux.centos6.x86_64/lib /usr/bin/python -c 'import numpy.linalg.lapack_lite'
$ (no import error)

Recompiling compat-libgfortran-41-4.1.2-44.el7 with '-lquadmath' explicitly added to the LDFLAGS also makes it work.
Steps To ReproducePrerequisites:
* gcc 4.1.2 - vanilla build on centos6 or the system gcc on centos5
* atlas 3.8.4 built with gcc 4.1.2

* Build numpy 1.7.1 with Atlas 3.8.4 support with gcc 4.1.2:
* * Add the Atlas include/lib paths to the site.cfg file.
* * Build the module:
$ /usr/bin/python build

* Try to import on the build machine. It works.
$ cd <build-dir>/build/lib.linux-x86_64-2.6
$ /usr/bin/python -c 'import numpy.linalg.lapack_lite'
$ (no import error)

* Try to import the on CentOS7. It fails.
$ cd <build-dir>/build/lib.linux-x86_64-2.6
$ env LD_LIBRARY_PATH=/software/python/2.6.4/linux.centos6.x86_64/lib /usr/bin/python -c 'import numpy.linalg.lapack_lite'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: /lib64/ undefined symbol: sqrtq
TagsNo tags attached.




2018-09-05 19:58

manager   ~0032655

[root@centos7 ~]# yum install numpy
Loaded plugins: priorities
Resolving Dependencies
--> Running transaction check
---> Package numpy.x86_64 1:1.7.1-13.el7 will be installed
--> Processing Dependency: python-nose for package: 1:numpy-1.7.1-13.el7.x86_64
--> Processing Dependency: for package: 1:numpy-1.7.1-13.el7.x86_64
--> Processing Dependency: for package: 1:numpy-1.7.1-13.el7.x86_64
--> Processing Dependency: for package: 1:numpy-1.7.1-13.el7.x86_64
--> Processing Dependency: for package: 1:numpy-1.7.1-13.el7.x86_64
--> Running transaction check
---> Package atlas.x86_64 0:3.10.1-12.el7 will be installed
---> Package lapack.x86_64 0:3.4.2-8.el7 will be installed
--> Processing Dependency: for package: lapack-3.4.2-8.el7.x86_64
---> Package libgfortran.x86_64 0:4.8.5-28.el7_5.1 will be installed
---> Package libquadmath.x86_64 0:4.8.5-28.el7_5.1 will be installed
---> Package python-nose.noarch 0:1.3.7-1.el7 will be installed
--> Running transaction check
---> Package blas.x86_64 0:3.4.2-8.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

 Package Arch Version Repository Size
 numpy x86_64 1:1.7.1-13.el7 base 2.8 M
Installing for dependencies:
 atlas x86_64 3.10.1-12.el7 base 4.5 M
 blas x86_64 3.4.2-8.el7 base 399 k
 lapack x86_64 3.4.2-8.el7 base 5.4 M
 libgfortran x86_64 4.8.5-28.el7_5.1 updates 299 k
 libquadmath x86_64 4.8.5-28.el7_5.1 updates 188 k
 python-nose noarch 1.3.7-1.el7 base 276 k

Transaction Summary
Install 1 Package (+6 Dependent packages)

Total download size: 14 M
Installed size: 47 M
Is this ok [y/d/N]: y
Downloading packages:
(1/7): blas-3.4.2-8.el7.x86_64.rpm | 399 kB 00:00:00
(2/7): libquadmath-4.8.5-28.el7_5.1.x86_64.rpm | 188 kB 00:00:00
(3/7): libgfortran-4.8.5-28.el7_5.1.x86_64.rpm | 299 kB 00:00:00
(4/7): numpy-1.7.1-13.el7.x86_64.rpm | 2.8 MB 00:00:01
(5/7): python-nose-1.3.7-1.el7.noarch.rpm | 276 kB 00:00:00
(6/7): atlas-3.10.1-12.el7.x86_64.rpm | 4.5 MB 00:00:02
(7/7): lapack-3.4.2-8.el7.x86_64.rpm | 5.4 MB 00:00:02
Total 4.6 MB/s | 14 MB 00:00:03
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : libquadmath-4.8.5-28.el7_5.1.x86_64 1/7
  Installing : libgfortran-4.8.5-28.el7_5.1.x86_64 2/7
  Installing : atlas-3.10.1-12.el7.x86_64 3/7
  Installing : blas-3.4.2-8.el7.x86_64 4/7
  Installing : lapack-3.4.2-8.el7.x86_64 5/7
  Installing : python-nose-1.3.7-1.el7.noarch 6/7
  Installing : 1:numpy-1.7.1-13.el7.x86_64 7/7
  Verifying : atlas-3.10.1-12.el7.x86_64 1/7
  Verifying : blas-3.4.2-8.el7.x86_64 2/7
  Verifying : 1:numpy-1.7.1-13.el7.x86_64 3/7
  Verifying : lapack-3.4.2-8.el7.x86_64 4/7
  Verifying : libgfortran-4.8.5-28.el7_5.1.x86_64 5/7
  Verifying : libquadmath-4.8.5-28.el7_5.1.x86_64 6/7
  Verifying : python-nose-1.3.7-1.el7.noarch 7/7

  numpy.x86_64 1:1.7.1-13.el7

Dependency Installed:
  atlas.x86_64 0:3.10.1-12.el7 blas.x86_64 0:3.4.2-8.el7 lapack.x86_64 0:3.4.2-8.el7
  libgfortran.x86_64 0:4.8.5-28.el7_5.1 libquadmath.x86_64 0:4.8.5-28.el7_5.1 python-nose.noarch 0:1.3.7-1.el7

[trevor@centos7 ~]$ python
Python 2.7.5 (default, Jul 13 2018, 13:06:57)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-28)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy.linalg.lapack_lite

Looks more like a problem with you building stuff from source to me.


2018-09-05 20:05

reporter   ~0032656

Hi Trevor

This is an issue with the compat package of libgfortran. I wish I could recompile every piece of production code when we change OS. :-) However we had to upgrade to CentOS7 and still require to run old, compiled code (centos6 with gcc 4.1.2 - long story, more info on the why: CY2014 @ )

So I'm needing to use on CentOS7 which has the linkage problem. shipping with libgfortran-4.8.5 has no issues.


2018-09-06 07:22

administrator   ~0032658

why not just run your legacy CentOS-5/6 code in a container (docker or singularity from EPEL) ?


2018-09-07 16:23

reporter   ~0032680

At this point it would just add complexity. Our code (using numpy) runs in pythons embedded in multiple applications (we share the same python code with many applications [all shipping with python2.7.x]) so isolation efforts would be fairly difficult.
As far as I know the compat-* packages are there to support running legacy code in a current release which is what I'd like to do.

If you omit all I wrote about the steps to reproduce the issue and just consider the undefined symbols in and the missing linkage that should give enough base for this bug report.

Issue History

Date Modified Username Field Change
2018-09-05 19:04 robbiesz79 New Issue
2018-09-05 19:58 TrevorH Note Added: 0032655
2018-09-05 20:05 robbiesz79 Note Added: 0032656
2018-09-06 07:22 tru Note Added: 0032658
2018-09-07 16:23 robbiesz79 Note Added: 0032680