I have a C static library (foo.a) built for arm64 target (aarch64-unknown-linux-musl). I need to call some C functions in that library from my Rust project.
How do I link to that pre-existing library (foo.a) without building it?
I defined extern C functions for my library so technically, if I can link to it, I should be able to use it from Rust code?
extern "C" {
pub fn somefunc();
}
The problem I run into is that Cargo rust build wants to use the default toolchain (stable-x86_64-unknown-linux-gnu) and I don't have my library compiled for that target. Can I customize Cargo build to not require stable-x86_64-unknown-linux-gnuand simply link against existing pre-compiled library for another target platform?
I tried modifying rust project settings to change default rustup default <toolchain>; but cargo build did not recognize the target aarch64-unknown-linux-musl. Then I tried to change build dependency to specify foo.a as static lib for my target.
[build-dependencies]
foo = { artifact = "staticlib", version = "1.0", target = "aarch64-unknown-linux-musl" }
Related
I have been given a static library(.a) by my client for my project. The objective of this static library is to integrate the functionality present in the library to my project.
The problem I'm facing is that when I'm trying to link this file, my linker could not link it and throws error.
Eg: consider the library has a function defined "void get_input ()". When I trying to invoke this function in my c file, my linker throws the error that the symbol is undefined.
I'm using Greenhills compiler.
I'm building a project that uses cmake.
The project uses three shared libraries .so files.
In the CMakeLists.txt file I've added the these lines which link the shared libraries to the executable.
project (lwm2mclient)
LINK_DIRECTORIES(/home/mraa-master-built/build/src)
LINK_DIRECTORIES(/home/libi2capi)
LINK_DIRECTORIES(/home/libtca6424a)
target_link_libraries (lwm2mclient libmraa.so m libi2capi.so libtca6424a.so)
However, one of the shared libraries libtca6424a.sodepends on libi2capi.so i.e. it uses methods that are defined in it.
So when I'm building the cmake project I get an error like this saying that the .so file cannot find the method which is defined in the other .so file libtca6424a.so.
Could somebody suggest a solution?
/../../lib/libtca6424a.so: undefined reference to `i2c_write_byte_data'
Please try
target_link_libraries (-Wl,--start-group lwm2mclient libmraa.so m libi2capi.so libtca6424a.so -Wl,--end-group)
or change the order of the libraries
I am building some test cases for a library. There a function is declared and used throughout the library. lib.a.
I then built up some test cases and implemented those functions, which are not declared in that library in a executable tests.exe
When I build test.exe it gives the error "Undefined reference to ....." How do I link correctly, I am using Eclipse and CppUnit. I have linked to the .a library and that .a library is building fine, I just can't link the two.
I’m cross compiling my C projects using Eclipse CDT/CodeSourcery Lite on Ubuntu v12.10.
In Eclipse CDT, I have these three C projects:
exeTop // executable that uses functions defined in libmiddle.a
libmiddle.a // static library that uses functions defined in libbottom.a
libbottom.a // standalone static library that doesn’t
depend on any other libraries
In order to build libmiddle.a, I have to copy libbottom.a into libmiddle’s project folder (see instructions here), which makes sense as libmiddle.a depends on libbottom.a.
However when building exeTop, I not only have to link to libmiddle.a but to libbottom.a (which libmiddle.a has already linked to).
Q1. Why is it required to link to libbottom.a from exeTop?
Q2. Are there any compiler or linker options I can use so that I can just link to libmiddle.a from exeTop?
You say "In order to build libmiddle.a, I have to link to libbottom.a, which makes sense as libmiddle.a depends on libbottom.a." I do not think this is the case at all. In fact, libmiddle.a can't really link against libbottom.a, because that's not how static libraries work on Linux. Static libraries are just "archives" of object files, and don't have a feature that makes them depend on other static libraries. Nor is it typical to stuff a static dependency into a static library itself.
For some more details, see [UNIX] : Do I need to add all libraries in my project's makefile, that are used from a library, used in my project?
Ok, so here's my question:
I have a working DUB project which produces an application. I decided I also wanted a "library" configuration in my dub.json file:
"configurations": [
{
"name": "application",
"targetType": "executable"
},
{
"name": "library",
"targetType": "library",
}
],
So, now when I build the project using dub build --config=library, it produces a libXXXX.a file in the same directory.
So far, so good.
I tried using this library (actually a tiny test-function marked as extern "C" from a test C app).
So, I compile my C app using gcc -c ctest.c and then link them all together like dmd libMYLIBRARY.a ctest.o.
Now, here is the problem:
In this last step, the linker complains that many symbols are missing - all coming from external dependencies (2 object files and several .a libraries) that would normally be linked when building the project as an application.
So, the question is... how do I solve this?
I mean... Should I just link my test C app against ALL of the original dependencies (this would not make the library very portable admittedly), or is there any way around it, so that anybody could use my library, only by linking against my libXXXXX.a file?
Should I just link my test C app against ALL of the original dependencies (this would not make the library very portable admittedly),
This is the "technically correct" answer. The reason for that is because, otherwise, if the C app wanted to use another D library which had among its dependencies some package that's also a dependency in your library, and if it were linked in the same way (including all of its dependencies in its static library file), this dependency would then occur twice in the linker inputs. Even if you told the linker to discard one copy, there can be problems due to the dependency being of separate incompatible versions, etc. (Note that there is an ongoing D SAOC project to handle this.)
If you were to assume that the only D library the C program will use is your Dub package, then you could conceivably create a static library which includes all dependencies, though it would probably need to include the D standard library and runtime as well.