I'm Linux rookie and I'm trying to move my library from windows to Linux. It is native binary (mylib.so), but it will be loaded by mono ( [DllImport()] ). I'm using a pcre (Perl Compatible Regular Expressions) in this library. When my .NET executable tries to load mylib.so it throws exception (lib not found). When I set MONO_LOG_LEVEL=debug. I says that my library is found, but pcre library is not.
I've tried to to load it dynamically (dlopen(), dlsym()). When I build executable version of my library linking it with dl (-ldl) it works fine. But when I load it from mono I got SIGSEGV.
I create this library like (for version with dl):
g++ -fPIC -c *.cpp
g++ -shared -Wl,-soname,libmylib.so.1.1 -ldl -o libmylib.so.1.1 *.o
I've create simple test program that link against mylib.so and dl (-l:libmylib.so.1.1 -ldl) and it works.
I think I need to force mylib to link with dl (or directly with pcre), but I don't know how. (I hope it's possible)
All what I want is to create library that use pcre and work under mono.
You incorrectly linked your library: if it uses libpcre you must link it, too, with the -lpcre option.
Related
I have a shared library (*.so) created using Real View Compiler Tools (RVCT 3.2) on windows target. Then I try to link this *.so file with my application using gcc on linux system.
What is the gcc option to link this shared library with my application linux?
My question is, is the -shared option, which is used as
gcc -shared myfile.so
..., used to create the SO file or to link the SO file? I believe it creates something like:
gcc -lmyfile.so
Is this enough? Or is there any other switch to tell the linker that it's a dynamic library (shared object)?
What worked for me was:
gcc -L. -l:myfile.so
gcc -lmyfile should be enough (provided that your library is named libmyfile.so). The linker searches for shared objects when possible and AFAIK prefers them.
I don't understand the difference between the two types of libraries, and many websites say that they are the same thing, but at school we use two different commands to create them
dynamic library
$ gcc -shared -o libsample.so lib.c
$ gcc -o main main.c -ldl
to execute:
$ ./main ./libsample.so
shared library
$ gcc -shared -o libsample.so lib.c
$ gcc -o main main.c -L. -lsample
to execute:
$ LD_LIBRARY_PATH=. ./main
Can someone help me in understanding the difference between the two "codes"?
Dynamic Linked Library (.DLL) is the terminology used by Microsoft Windows. Shared Object (.so) is the terminology used by Unix and Linux.
Other than that, conceptually they're the same.
Regarding your snippets of commands, I guess the difference (and I'm only guessing here, because you didn't show us the relevant parts) is how the library is loaded. There is "link time loading" where the library is tied to the executable by the linker¹. And there is "runtime loading", where the program sort of "ingests" the dynamic/shared library.
runtime loading is done in Windows with the LoadLibrary (there's an …A and a …W variant) function, and on Unix/Linux with dlopen (which is made available by libdl which is linked to by that -ldl library link statement).
1: The linker is the program that creates the actually executable file from the intermediary objects created by the various compiler stages.
Dynamic and shared libraries are usually the same. But in your case, it looks as if you are doing something special.
In the shared library case, you specify the shared library at compile-time. When the app is started, the operating system will load the shared library before the application starts.
In the dynamic libary case, the library is not specified at compile-time, so it's not loaded by the operating system. Instead, your application will contain some code to load the library.
The first case is the normal case. The second case is a special use and it's mainly relevant if your application support extensions such a plug-ins. The dynamic loading is required because there can be many plug-ins and they are built after your application. So their names are not available at compile-time.
I have a JNI project, which I have to make work on Windows (I am working on Linux). This project actually depends on third-party library file which is static (archived i.e .a files). I am trying to create a JNI shared library file using i686-w64-mingw32-g++ and including -static followed by static third-party library name. Following is the command I am using
i686-w64-mingw32-g++ -v -L./ -L/home/user/jre1.8.0_40/lib/amd64/ -I/user/all/apps/Linux2/x86_64/gcc/4.8.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2/include -shared -o test.dll test.cpp -lstdc++ -static -thirdparty
In-spite of placing the third party library in the current working directory, I keep getting error
/user/all/apps/Linux2/src/mxe/2013_12_03/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.1/../../../../i686-w64-mingw32/bin/ld: cannot find -thirdparty
Please note : I included -I/user/all/apps/Linux2/x86_64/gcc/4.8.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2/include to avoid the error cannot find jni.h which I hit before including the path.
I also tried to compile using gcc, in place of g++.
Do I need to create .dll of this third-party library(currently it is archived .a containing .obj files)?
Being a newbie in cross compilers, I might be doing something wrong. Please correct me and any suggestions with this will be very helpful. Thank you.
-Wl,--export-all-symbols -Wl,--add-stdcall-alias -v adding this solved my problem
If you would create a library with c, that depends on another library, say cURL, you would compile it to a static library like this:
clang myLibrary.c -lcurl -c
ar myLibrary.a myLibrary.o
But, if you were to include this library in your application, you would get an error because some functions were not found (the cURL ones).
Is there a way to include libraries (in this case cURL) in the library at compile time?
I'm working on a linux machine
How do I convince LibTools to generate a library identical to what gcc does automatically?
This works if I do things explicitly:
gcc -o libclique.dylib -shared disc.c phylip.c Slist.c clique.c
cp libclique.dylib [JavaTestDir]/libclique.dylib
But if I do:
Makefile libclique.la (which is what automake generates)
cp .libs/libclique.1.dylib [JavaTestDir]/libclique.dylib
Java finds the library but can't find the entry point.
I read the "How to create a shared library (.so) in an automake script?" thread and it helped a lot. I got the dylib created with a -shared flag (according to the generated Makefile). But when I try to use it from Java Native Access I get a "symbol not found" error.
Looking at the libclique.la that is generated by Makefile it doesn't seem to have any critical information in it, just looks to be link overloads and moving things around for the convenience of subsequent C/C++ compiler steps (which I don't have), so I would expect libclique.1.dylib to be a functioning dynamic library.
I'm guessing that is where I'm going wrong, but, given that JNA links directly to a dylib and is not compiled with it (per the example in the discussion cited above), it seems all the subsequent compilation steps described in the LibTools manual are moot.
Note: I'm testing on a Mac, but I'm going to have to do this on Windows and Linux machines also, which is why I'm trying to put this into Automake.
Note2: I'm using Eclipse for my Java development and, yes, I did import the dylib.
Thanks
You should be building a plugin and in particular pass
libclique_la_LDFLAGS = -avoid-version -module -shared -export-dynamic
This way you tell libtool you want a dynamically loadable module rather than a shared library (which for ELF are the same thing, but for Mach-O are not.)