#139 Missing symbol dlamc3_ with 3.9.17/3.9.16

[David Warde-Farley]

Hi,

For some reason when I build ATLAS, with or without using ATLAS's --with-netlib-lapack-tarfile (or assembling liblapack.a myself), when I try and use NumPy built against it I get an error at runtime saying dlamc3_ is not found. It works fine when I build and link against ATLAS 3.9.11; I haven't tried 12-15.

The flags I'm using are ../configure -Ss kern /usr/bin/gcc-4.2 --prefix=/opt/sw/ATLAS -t 4 -D c -DPentiumCPS=2668 -b 64 -Fa alg '-fPIC' --with-netlib-lapack-tarfile=/home/dwf/tmp/lapack-lite-3.1.1.tgz

The build and install seem to proceed without incident and 'make test' doesn't turn up any problems, but the symbol seems to be missing when NumPy tries to use it. Any idea why?

[David Warde-Farley]

For completeness I have attached the error report as requested, though I had to bz2 rather than gzip it since SourceForge insists it is >256k.

[R. Clint Whaley]

David,

Well, dlamc3 is an internal routine called by dlamch in LAPACK in order to keep register assignment from screwing up their internal tests. It is not part of the official LAPACK API AFAIK. It looks like some part of NumPy is calling this routine, expecting that DLAMCH will provide it. However, from 3.9.16 on, ATLAS provides a native LAMCH implementation, that reads in a generated file for improved speed. This LAMCH does no computation at all, and so obviously does not provide the internal routine DLAM3.

Can you ask the NumPy people to comment on why they are calling this routine?

Thanks,
Clint

[Anonymous]

I have got the same dlamc3 and slamc3 problem as reported in ID 2899939 "Fail to create dll".

I checked the existence of dlamc3 in liblapack.a by executing "nm liblapack.a". There are dlamc[12345h] in liblapack.a of atlas-3.9.16. However, There is only dlamch in liblapack.a of atlas-3.9.17. By checking the error message posted in ID 2899939 "Fail to create dll", I can see that dlamc3 and slamc3 are called by reference lapack routines but they are not in liblapack.a of atlas-3.9.17.

[Anonymous]

I show an example which routine calls dlamc3, DSTEDC.

dstedc -> dlaed0 -> dlaed1 -> dlaed3 -> dlamc3

[David Warde-Farley]

Hi Clint,

Thanks for you reply. As sf1021 mentioned, there are .o files inside the generated liblapack that reference dlamc3_, for example:

root@mirage:/opt/sw/ATLAS/lib/tmp# grep -l dlamc3_ *
dlaed3.o
dlaed9.o
dlals0.o
dlasd3.o
dlasd8.o
zlals0.o

NumPy isn't calling dlamc3_ directly, but rather is going through the public LAPACK API, it seems. grepping the LAPACK sources seems to indicate the same:

root@mirage:~/src/tarball/lapack-lite-3.1.1/SRC# grep -il dlamc3 *.f
dlaed3.f
dlaed9.f
dlals0.f
dlasd3.f
dlasd8.f
zlals0.f

(There are references to it in the NumPy sources as NumPy ships with an f2c'ed LAPACK that it falls back on if no real LAPACK is available, but removing all these files from the build yields the same errors.)

Best,
David

[R. Clint Whaley]

David,

OK, I confirm the bug in ATLAS. I will need to add dlamc3 to the Fortran interface to ATLAS, since so many LAPACK routines call it.

In the meantime, take dlamc3 extracted from lapack/SRC/INSTALL/dlamch.c and manually put it into your liblapack.a library. I will attach the extracted file to this error report to make it easier.

As a note to self: none of the other lamc# routs are externally used.

Thanks for reporting this error,
Clint

[R. Clint Whaley]

extracted dlamc3

[R. Clint Whaley]

slamc3.f

[R. Clint Whaley]

This problem is fixed in the basefiles, so I should be able to close this bug report when I release 3.9.19. I have attached slamc3.f to this report, which you'll need for the s & c routs.

[R. Clint Whaley]

This should be fixed in 3.9.19. Can you please confirm if it is with a comment, and reopen the bug report if the problem persists?

Thanks,
Clint