I need to create a (static) C library that binds to existing crate. Is there any way Cargo can create this C library for me?
I have a crate (e.g. html5ever), and I want Cargo to create a C library based on C-API for that crate.
Is there any way Cargo can create this C library for me?
Cargo does not currently have this feature.
I have a crate (e.g. html5ever), and I want Cargo to create a C library based on C-API for that crate.
Is there a reason that it is in C? C can call into Rust code directly, you could just use html5ever as it exists.
A way to solve this problem is to create a special crate which stores your C API. For example if your library is called foo, then have inside your main directory another folder alongside src/tests called capi, which will store a special crate foo_capi for C API.
foo
|
+--src
|
+--test
|
+--capi
|
+--include
|
+--src
|
Cargo.toml
include folder contains header files for C.
src contains the Rust files which are exported into C.
The Cargo manifest should be statically linked and have a dependency on the project foo. For example check out this Cargo.toml used in html5ever.
I think, cargo-c is excatly what you are looking for:
It produces and installs a correct pkg-config file, a static library and a dynamic library, and a C header to be used by any C (and C-compatible) software.
Related
I have asked this question on linux, but now I need the same info on macos... The question is (adapted to macos):
I am trying to create a shared library, libbar.dylib, that embeds a commercial static library (licensing is fine). The commercial library has 4 versions: libfoo-seq.a, libfoo-mt.a, libfoo-seq.dylib, and libfoo-mt.dylib (they all provide the same symbols, just the code is sequential/multi-threaded, and the lib is static/shared). Of these four I want my code always to use the sequential foo library, so when I create libbar.dylib I link together my object files and libfoo-seq.a.
The problem is that the users of my library may have already pulled in libfoo-mt.dylib by the time they pull in my libbar.dylib, thus all symbols from libfoo are already present by the time libbar.dylib is read in, so my calls to the functions in foo are resolved to the multithreaded version. At least I think this is happening. Is there any way to double check?
If this is really what is happening, I wonder how can I resolve this issue? What kind of magic flags do I need to use when I compile to create my object files and when I link my object files with libfoo-seq.a to create libbar.dylib?
I must use an external toolchain in order to compile some source code I'm given. The source code doesn't come with a Configure file, only with a, what seems to be, automatically generated Makefile.
The Makefile makes references to mips-linux-[cc|ar|ld|...], but the toolchain I'm provided has a different naming.
Is there any way I can tell make to use another naming scheme?
Answer is: CROSS=my-custom-toolchain-prefix
I was wondering if there was a way to create my own custom library , that would be visible for all future projects, and not just the current one ?
The library is supposed to be just a simple header file (.h) with all the libraries I need to work with already included in it. I've tried searching the web for a way to do it, but I had no luck in finding such a way. If anyone knows how to, it would be greatly appreciated. Thanks in advance.
In order to make your own library, you can follow these general steps;
Let's say you want to make a library mlib
First of all create an Interface of your library: mylib.h
Implement your library in mylib.c
Compile your c file and your will get object fiile with extention .o in linux that can be linked with programs that want to use our library code
Now you can include your header in your new program where you want to use your library and provide link of your object excuteable to compiler when compiling your program.
#include
// rest of your program
now for compiling
clang -o myprogram myprogram.c -lmylib
Is there a way of doing this?
Develop a library L1 written in Golang. L1 exports functions for C language.
Build L1 and generate .lib file for Visual C++.
Use L1 from Visual C++ code by calling C functions in L1.
I've never tried, and I'm using linux, but here is what I know:
According to the golang documentation you can compile go code into shared library (see go help buildmode also).
To be able to call go function from c code, go function shall be exported.
In order to compile your go code into a shared library, you need to get the go standard library into a shared one too:
go install -buildmode=shared std
This will compile all the go standard code into libstd.so (on linux, the name might change on windows).
And finally, you can use the following command to get your shared library:
go install -buildmode=shared -linkshared [packages]
The standard shared library can be found in:
GOROOT/pkg/GOOS_GOARCH_dylink/
and your shared library under:
GOPATH/pkg/GOOS_GOARCH_dylink/
That is for the go part.
Now, if you want to call this code from a C++ project, you'll need to create the C library that wraps the go library. You can use some tool for that (I've heard about SWIG, but never tried).
EDIT: You can do something similar with static go library, but since you did not specify the library type and you will use it from C++ code, I suppose you need a shared library.
I am on OS X, and I have a .so file which I want to link to a .o file during execution. For example Foo.so should be linked to Bar.o during while calling ./Bar.o . I am using the Terminal application to run my app and I compiled my project using a Makefile.
On Unix and OS X you can do this with libdl.
The basic idea is that you compile and link an executable. At some possibly different point in time and place, someone who might not be you compiles and links a shared libray. If at runtime the executable can get strings for the the shared library filename and the symbol of a function that you want to load, then you can use libdl to get a void* to that contains the address of a function in the shared lib. The appropriate function pointer type must be known to the executable at compile time because the next step is to cast the void* to whatever type was "secretly prearranged" between the executable and the dynamically loaded lib. After casting you're good to go.
This tutorial shows the traditional approach for dynamically loading functions. Classes requires some indirection via factory functions.
http://www.tldp.org/HOWTO/html_single/C++-dlopen/
The approach above is where to start but it has the drawback that all communication between the executable and lib must be through C style function signatures created with extern "C" before functions (most significantly no templates or overloads). This is just a limitation on the ports of communication between the executable and lib. Both can use C++ internally. If you want to dynamically import overloaded functions here's a way.
Dynamic Loading Without extern "C"
You have to be careful with user defined classes. The binary representation of classes is not standardized in C++. If a custom class passes from executable to lib but the executable and lib have different ideas of which bits mean what, you won't get the behavior you wanted.
Also, if you compiled your shared library on OS X, you have a dylib, not an so. They're slightly different.
What are the differences between .so and .dylib on osx?