error: building the downstream libh3 C library using the Solana SDK via cmake #30
Comments
|
Hi, Seems this is caused by the Try switching your dependency from the crates.io version "0.13" to latest master from git and see if the problem persists. |
|
Thanks for your help I get this error now |
|
Just so you know this is what the npm command that I am running is doing ( |
|
Seems the crossbeam issue is solved - great. Now the problem is building the downstream libh3 C library using the Solana SDK via cmake. It appears cmake correctly detects the C compiler of the SDK, but is not able to find a suitable linker. So it falls back to your systems default linker, but that one does not support the bpfel architecture. I suppose there should be a suitable linker with in the SDK in the same directory as the compiler found by cmake. Messing with cmake can be tricky, but https://stackoverflow.com/questions/1867745/cmake-use-a-custom-linker gives some hints. The |
|
@nmandery I think I am getting onto something. |
|
Also I am seeing that I |
|
The h3ron-h3-sys crate compiles its own copy of the h3 library when the crate is build. This happens here https://github.com/nmandery/h3ron/blob/master/h3ron-h3-sys/build.rs#L15 and is done using cmake. The reason for this is to be able to do a static linking of the rust code to the C library and to be independent of h3 being installed with the system libraries. That means all information about the environment we are compiling for must go there. That works great for the Solana-specfic compiler as this is set in the Please have a look in cmake supports the First run Try to build your project with something like cargo clean
export CFLAGS="-fuse-ld=/home/pc/.local/share/solana/install/releases/1.9.2/solana-release/bin/sdk/bpf/dependencies/bpf-tools/llvm/bin/lld"
npm run build:program-rustThats a quite long chain of build tools calling build tools - so hopefully this is of help to you. libm should be contained in the LLVM of the SDK, I suppose. Some related links: |
|
I have switch to use 1.9.4 I hope its ok. all good the output it says: |
|
Nice that clang gives us this warning. Try to use the |
|
Thanks all good I am cleaning each time with I have open a new window to get rid of the CFLAGS and only have the LDFLAGS defined also this is the beginning of the trace. I see clang - broken |
|
gcc calling clang? Things are getting confusing ;) Also interesting that the flag is not understood. One more attempt, if this does not work, I am slowly running out of ideas: unset CFLAGS
unset LDFLAGS
# search in the SDK first
export PATH="/home/pc/.local/share/solana/install/releases/1.9.4/solana-release/bin/sdk/bpf/dependencies/bpf-tools/llvm/bin/:$PATH"
cargo clean
# ... then build |
|
That |
|
well back to the beginning I think. Thanks for your help, really appreciate it |
|
Solana allows you to build C program or Rust program. This would be for the C program. When I say |
|
No worries. I have to confess I do not understand much of the blockchain terminology ;) Looking at https://github.com/solana-labs/solana/blob/master/sdk/bpf/c/bpf.mk it seems to contain the flags needed to compile C code for the pbf architecture. Maybe the compilation here works when you extract flags from the files In case that gives conflicts with the rust compilation, maybe putting them directly into h3ron-h3-sys Thats the command to compile C for solana: https://github.com/solana-labs/solana/blob/master/sdk/bpf/c/bpf.mk#L159 In the example you linked that |
johhnsmmith198
changed the title
crossbeam-epoch while including this lib in solana helloworld example
|
@nmandery running the same |
|
Would it help when we implement a feature-flag to compile libh3 without cmake using the |
|
@nmandery I would like to ask a few questions. |
|
The libh3 C-sources are actually bundled in the h3ron-h3-sys crate when its downloaded from crates.io. The build of the C sources is done by the There is no possibility to pass custom flags to the cmake command - I am not aware of any way to do such things using cargo. The reason cmake is often used is that it figures out the correct settings for the host-system itself. Thats also the reason why cmake compiles the "simple test program" (see the cmake output) - it does so simply to validate its able to build. The basis for cmake being able to find the compiler etc are environment variables - these here are the supported ones. These can be used to pass information to cmake in a way which should also work with cargo being in between. On your system for example The tricky part here is that cmake is not supposed to build for the host system, but instead should be cross compile for solana. CMake has documentation how to use it for cross compilation: https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-compiling-toolchain - setting CMAKE_CROSSCOMPILING to disable the compiler checks could be a step in the right direction. In case this can not be resolved using environment variables, perhaps forking the repo and modifying the |
|
@nmandery thanks for your help. |
|
You could leave out lines 12 and 15 - everything else you will still need though. You also got to change the You can choose between two kinds of linkage, static and dynamic. I am using static linking to produce a single binary with libh3 being contained within. I am also not sure if solana and bpf support dynamic linking. |
|
#47 drops the requirement for cmake and compiles h3 with the |
|
Closing as there is now h3o which provides a rust implementation of H3. |
Hi,
solana has this helloworld program that you can build (and deploy on a validator): https://github.com/solana-labs/example-helloworld
It works well before adding the h3ron library.
adding this dependency:
and running:
would generate this error
Could you please help?
The text was updated successfully, but these errors were encountered: