Rust bindings fail to build built-in backends on Darwin aarch64 #1694
Comments
|
Are you using static or shared libraries? Does it work from C when you make the same choice? I suspect it's a linker interaction with weak symbols, but would like to narrow down how. |
|
I was building this in the default configuration of the bindings (i.e. static link). I just tried to build |
|
Can you build with Could you also show output of |
|
|
Hmm, seems the weak attribute is being lost. Do you know how to make those by a $ nm lib/libceed.a |rg CeedRegister_
U CeedRegister_Avx_Blocked
U CeedRegister_Avx_Serial
U CeedRegister_Cuda
U CeedRegister_Cuda_Gen
U CeedRegister_Cuda_Shared
U CeedRegister_Hip
U CeedRegister_Hip_Gen
U CeedRegister_Hip_Shared
U CeedRegister_Magma
U CeedRegister_Magma_Det
U CeedRegister_Memcheck_Blocked
U CeedRegister_Memcheck_Serial
U CeedRegister_Occa
U CeedRegister_Opt_Blocked
U CeedRegister_Opt_Serial
U CeedRegister_Ref
U CeedRegister_Ref_Blocked
U CeedRegister_Sycl
U CeedRegister_Sycl_Gen
U CeedRegister_Sycl_Shared
U CeedRegister_Xsmm_Blocked
U CeedRegister_Xsmm_Serial
000000000000032c T CeedRegister_Ref
0000000000000124 T CeedRegister_Ref_Blocked
0000000000000242 T CeedRegister_Opt_Blocked
000000000000022f T CeedRegister_Opt_Serial
00000000000001e8 T CeedRegister_Memcheck_Blocked
00000000000001fb T CeedRegister_Memcheck_Serial
0000000000000137 T CeedRegister_Avx_Blocked
0000000000000124 T CeedRegister_Avx_Serial
0000000000000132 W CeedRegister_Avx_Blocked
0000000000000158 W CeedRegister_Avx_Serial
000000000000017e W CeedRegister_Cuda
00000000000001a4 W CeedRegister_Cuda_Gen
00000000000001ca W CeedRegister_Cuda_Shared
00000000000001f0 W CeedRegister_Hip
0000000000000216 W CeedRegister_Hip_Gen
000000000000023c W CeedRegister_Hip_Shared
00000000000002d4 W CeedRegister_Magma
0000000000000301 W CeedRegister_Magma_Det
000000000000032e W CeedRegister_Memcheck_Blocked
0000000000000354 W CeedRegister_Memcheck_Serial
000000000000037a W CeedRegister_Occa
00000000000003c5 W CeedRegister_Opt_Blocked
00000000000003eb W CeedRegister_Opt_Serial
0000000000000411 W CeedRegister_Ref
0000000000000437 W CeedRegister_Ref_Blocked
0000000000000262 W CeedRegister_Sycl
00000000000002ae W CeedRegister_Sycl_Gen
0000000000000288 W CeedRegister_Sycl_Shared
0000000000000000 t CeedRegister_Weak
000000000000045d W CeedRegister_Xsmm_Blocked
0000000000000483 W CeedRegister_Xsmm_SerialWhat we do now is for |
|
Unfortunately I have no idea so far. I've now tried a range of different things from different toolchains (GCC 12, LLVM, Apple LLVM) to both different weak symbol markers (Apple "prefers" |
|
What I've done now as a workaround is the following: This works and, while ugly, this allows building libCEED as a dynamic library only on MacOS: This "fixes" my problem for now. Are you interested in having the small change in |
|
Does that end up requiring |
|
I have cargo build Also, I do not use |
|
I'm concerned there may be another libceed.dylib in your search path, but maybe that has been handled automatically for MacOS. This is a way to automate that on Linux. https://gitlab.com/petsc/petsc-rs/-/blob/main/examples/snes/build.rs?ref_type=heads Can we put the default feature selection entirely inside |
I just ran They were generated with
My understanding is that this used to be possible with the feature resolver V1 of Cargo, provided features are only added instead of removed with |
|
Okay, thanks. Would you mind putting what you're thinking in a branch? I still wonder if there is some mixing of Apple and gcc/clang upstream linking tools that is interfering with weak symbols, but perhaps it just doesn't work with static libs? |
|
I currently keep my small change in https://github.com/eliasboegel/libCEED. I use this as the Cargo dependency in my project, and disable At this point of static linking I also want to add that I did try a minimum example of weak linking on my MacOS machine - just a simple function in a static library as a weak symbol. I found that, while the symbols still weren't marked as |
Hi,
I was just trying to build both my own application as well as the Rust examples on a new machine, running an
aarch64Darwin system. The build of the interface appears to succeed (build process shows no errors), however running with any backend (even/cpu/self/ref/*and/cpu/self/opt/*) will result inBackend not currently compiled: /cpu/self Consult the installation instructions to compile this backend.I am currently using a standard Clang 16.0.6 toolchain, however the same issue occurs with an Apple Clang (15) distribution. Building and running the tests of the C library works without issue, so I don't see this being an issue with the
makeconfiguration. I'm currently still unsure if this is a libCEED issue with Bindgen or purely a Bindgen problem. It is also unclear if this is a Darwin problem, or anaarch64problem as I don't currently have neither an Intel Darwin or Linuxaarch64machine available.Have the libCEED Rust bindings previously successfully built under Darwin, especially on an
aarch64machine, or are there any ideas what the issue could be? My (unsubstantiated) suspicion is a linker issue.The text was updated successfully, but these errors were encountered: