OpenBLAS @0.2.17_0: "Undefined symbols for architecture x86_64"

[Schamschula (Marius Schamschula)]

While building OpenBLAS 0.2.17 under Yosemite, I get a series of "Undefined symbols for architecture x86_64" errors.

[michaelld (Michael Dickens)]

Builds for me cleanly with default variants on 10.11 latest.

[michaelld (Michael Dickens)]

The compile command is a strange mix of Clang and GCC. What variants are you using for the build?

[Schamschula (Marius Schamschula)]

I've got the +clang +lapack variant

[NicosPavlov]

I can't reproduce the issue either, and I don't see any difference in the linking instructions. There had been some issues about CPU architectures in the past, but that does not seem to be that. It seems that some symbols are missing from lapack, but I don't have a good clue of why at this point.

The mix between clang and gcc is because of the need of a fortran compiler for lapack, and we are using the gcc5 one by default in the clang variant.

[michaelld (Michael Dickens)]

Builds for me using your variants, on 10.11 latest. I'll can check on 10.10 tomorrow.

[matthew.grismer@…]

OpenBLAS build log

[matthew.grismer@…]

I am also getting the same errors trying to build on OS X 10.11.4 with the default variants (+gcc5 +lapack). Build log is attached.

[michaelld (Michael Dickens)]

Default variants are +clang +lapack, not +gcc5 +lapack.

Both the release and devel build for me either default variants, or with +gcc5 instead of +clang. The primary difference in that specific compile command in the log file between mine and yours is that mine has:

-L/opt/local/lib/gcc5/gcc/x86_64-apple-darwin15/5.3.0 -L/opt/local/lib/gcc5/gcc

both before and after -L/opt/local/lib. Yours just has these after, not before. I've no idea how to correct this issue if it even is one -- which I'm guessing this isn't the actual issue. That said, I'm at a loss as to what might be the actual issue. OpenBLAS is a very complex project!

[NicosPavlov]

I agree this should not be the issue. I just noticed that the missing symbols consist of a very specific subset of lapack functions, namely the matgen module, located in testing. I'll have to look in more details, but it is possible that a difference in configuration either prevents lapack of building this module, or triggers OpenBLAS to link to it.

[NicosPavlov]

I found a way to reproduce the issue, but I would like to check that it is the same one. So, could check the following after a build failure:

1. Are there object (*.o) files in SRCDIR/lapack-netlib/TESTING/MATGEN?
2. Could you post the following files here (after build failure)?

• SRCDIR/Makefile.conf
• SRCDIR/lapack-netlib/make.inc

[matthew.grismer@…]

Well, I did a port sync and then port upgrade outdated, and now OpenBLAS 0.2.17 builds and installs without issue... So, I guess the issue is fixed.

[NicosPavlov]

I see. Well, as this happened for two different users, and that nothing was changed to the port between the update to 0.2.17 and now, it would more seem to be a somewhat erratic error. I'll leave the ticket open for now in case something else pops up.

Fundamentally, my suspicion is that the configuration ends up with a NOFORTRAN=1 variable for whatever reason, and despite the presence of a fortran compiler, leading lapack to not build certain symbols required by OpenBLAS.

[NicosPavlov]

Additional note: I got the same error when trying to update OpenBLAS to 0.2.18. Then cleaning the install and rebuilding led to a full install, so it is clearly a non-reproducible error.

To answer my own questions:

1. Are there object (*.o) files in SRCDIR/lapack-netlib/TESTING/MATGEN?

Yes, the object files are present.

2. Could you post the following files here (after build failure)?

• SRCDIR/Makefile.conf
• SRCDIR/lapack-netlib/make.inc

No sign of any NOFORTRAN symbol.

It therefore seems to be an error either in ar when building the static library which misses symbols, or a linking issue when making the dynamic library.

[michaelld (Michael Dickens)]

since openblas is at 0.2.19, is this ticket still relevant?

[michaelld (Michael Dickens)]

With OpenBLAS now at 0.2.20, I'm closing this ticket as no longer relevant & fixed when some new release came out.

[jjstickel (Jonathan Stickel)]

I ran into this issue, or something similar, today with Mac OS 10.14.6 and OpenBLAS @0.3.8_0+gcc8+lapack

:info:build Undefined symbols for architecture x86_64:
:info:build   "_dgesvd_", referenced from:
:info:build       _LAPACKE_dgesvd_work in libopenblas-r1.a(lapacke_dgesvd_work.o)
:info:build      (maybe you meant: _LAPACKE_dgesvd_work)
:info:build   "_zpotrs_", referenced from:
:info:build       ___ctest_potrf_bug_695_run in test_potrs.o
:info:build ld: symbol(s) not found for architecture x86_64

I had interrupted the build (ctl+c) and restarted it, which rarely causes problems, but it seemed to trigger this issue. Cleaning and rebuilding resolved the problem. I am reporting here in case anyone else runs into this problem in the future.