Opened 5 years ago

Closed 3 years ago

Last modified 8 months ago

#50950 closed defect (fixed)

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

Reported by: Schamschula (Marius Schamschula) Owned by: NicosPavlov
Priority: Normal Milestone:
Component: ports Version: 2.3.4
Keywords: Cc: michaelld (Michael Dickens)
Port: OpenBLAS

Description

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

Attachments (2)

OpenBLAS-main.log.gz (183.0 KB) - added by Schamschula (Marius Schamschula) 5 years ago.
main.log.gz (178.7 KB) - added by matthew.grismer@… 5 years ago.
OpenBLAS build log

Download all attachments as: .zip

Change History (18)

Changed 5 years ago by Schamschula (Marius Schamschula)

Attachment: OpenBLAS-main.log.gz added

comment:1 Changed 5 years ago by michaelld (Michael Dickens)

Builds for me cleanly with default variants on 10.11 latest.

comment:2 Changed 5 years ago by michaelld (Michael Dickens)

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

comment:3 Changed 5 years ago by Schamschula (Marius Schamschula)

I've got the +clang +lapack variant

comment:4 Changed 5 years ago by 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.

comment:5 Changed 5 years ago by michaelld (Michael Dickens)

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

Changed 5 years ago by matthew.grismer@…

Attachment: main.log.gz added

OpenBLAS build log

comment:6 Changed 5 years ago by 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.

comment:7 Changed 5 years ago by 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!

comment:8 Changed 5 years ago by 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.

comment:9 Changed 5 years ago by 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

comment:10 Changed 4 years ago by 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.

comment:11 Changed 4 years ago by 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.

comment:12 in reply to:  9 Changed 4 years ago by 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.

  1. 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.

comment:13 Changed 3 years ago by mf2k (Frank Schima)

Cc: NicosPavlov removed
Owner: changed from macports-tickets@… to NicosPavlov
Status: newassigned

comment:14 Changed 3 years ago by michaelld (Michael Dickens)

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

comment:15 Changed 3 years ago by michaelld (Michael Dickens)

Resolution: fixed
Status: assignedclosed

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

comment:16 Changed 8 months ago by 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.

Note: See TracTickets for help on using tickets.