Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Undefined symbols when using cmake based build on macOS #4347

Closed
catap opened this issue Nov 28, 2023 · 4 comments · Fixed by #4348
Closed

Undefined symbols when using cmake based build on macOS #4347

catap opened this issue Nov 28, 2023 · 4 comments · Fixed by #4348

Comments

@catap
Copy link
Contributor

catap commented Nov 28, 2023

Hey,

I've discovered a wired issue when I've switched to cmake based build:

:info:build Undefined symbols for architecture x86_64:
:info:build   "_xerbla_", referenced from:
:info:build       _sgemv_ in libopenblas.a(sgemv.c.o)
:info:build       _sger_ in libopenblas.a(sger.c.o)
:info:build       _strsv_ in libopenblas.a(strsv.c.o)
:info:build       _strmv_ in libopenblas.a(strmv.c.o)
:info:build       _ssyr2_ in libopenblas.a(ssyr2.c.o)
:info:build       _sgbmv_ in libopenblas.a(sgbmv.c.o)
:info:build       _ssbmv_ in libopenblas.a(ssbmv.c.o)
:info:build       ...
:info:build      (maybe you meant: _xerbla_array_)
:info:build ld: symbol(s) not found for architecture x86_64

It appears on macOS 10.5 and 10.6 only when build calls gfortran with parameters -fpic -shared -Wl,-all_load -Wl,-force_load,libopenblas.a -Wl,-noall_load.

Since 10.7 this issue do not reproduced, and the major differences that since 10.7 it has libc++ and clang based "world". I not sure how it related, but it seems some condition inside cmake files aren't hold.

Does it ring any bell?

@martin-frbg
Copy link
Collaborator

Could be due to some tricks that are played so that xerbla can be overloaded with a user-provided error handler (which is e.g. what some tests use). I'm pretty sure that your libopenblas.a will have a _xerbla_ (even if as a weak symbol), but could you check with nm or equivalent just in case ?

@catap
Copy link
Contributor Author

catap commented Nov 28, 2023

Well, it has only U symbols and a lot of them:

leopard:build catap$ nm libopenblas.a | grep _xerbla_ | grep -v 'U'
warning: nm: no name list
warning: nm: no name list
00000000 T _xerbla_array_
leopard:build catap$ nm libopenblas.a | grep _xerbla_ | grep 'U' | wc -l
warning: nm: no name list
warning: nm: no name list
    1785
leopard:build catap$ 

But the same behaviour on macOS 12 as well where it works:

√ build % nm libopenblas.a | grep _xerbla_ | grep -v 'U'
libopenblas.a:xerbla.c.o: no symbols
libopenblas.a:la_constants.f90.o: no symbols
0000000000000000 T _xerbla_array_
√ build % nm libopenblas.a | grep _xerbla_ | grep 'U' | wc -l 
libopenblas.a:xerbla.c.o: no symbols
libopenblas.a:la_constants.f90.o: no symbols
    1785
√ build % 

@catap
Copy link
Contributor Author

catap commented Nov 28, 2023

BTW I may try to fix build by -undefined dynamic_lookup, let me take a spin

@catap
Copy link
Contributor Author

catap commented Nov 28, 2023

As expected it had been built. Building mumps to confirm that it works as expected. Which includes by dependencies scalapack, scotch and few other things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants