i am working on building glib library with ASAN, gcc version is 6.3 .
I am able to compile and build glib library with ASAN. My configure command is :-
../configure CC='/local/test/v6.3.0/bin/gcc' CXX='/local/test/v6.3.0/bin/g++' CFLAGS='-fPIC -O2 -fsanitize=address' CXXFLAGS='-fPIC -fsanitize=address' LDFLAGS='-L/local/test/v6.3.0/lib64 -lasan' LD_LIBRARY_PATH='/local/test/v6.3.0/lib64' --enable-static=yes --prefix=/home/testing/debug_glib/glib-2.56.1/testing_glb --enable-libmount=no PYTHON=/local/test/pkgs/python/v2.7.6/bin/python --with-pcre=/home/testing/pcre_lib/pcre-8.20/pcre_library
Here when i try to use newly created glib library, I am hitting undefined reference to symbol issue :
$ /local/test/client_new/test_build/kkl/tools/kenzip -c dcltotb.tcl
/home/testing/lib/libglib-2.0.so: undefined symbol: __asan_option_detect_stack_use_after_return
I am linking ASAN library (-lasan) which has above symbol defined in it. Any thing missing here? Please help!
Thanks in Advance.
Build the latest version of GLib (2.62.4). It is built using Meson, rather than autotools, and you can enable ASAN by passing -Db_sanitize=address to meson when configuring the build.
First you need to correct your LDFLAGS to be
LDFLAGS=-fsanitize=address
Then, you need to preload libasan when running your unsanitized
executable with
LD_PRELOAD=path/to/libasan.so /local/test/client_new/test_build/kkl/tools/kenzip -c dcltotb.tcl
Related
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
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.
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.)
I want to link an existing shared library (FlashRuntimeExtensions.so) to my C-code while compiling my own shared library. But whatever I try I always get the same error; that the file is in a wrong format. Does anybody have an idea on how to solve this?
Here is my compile command:
$ g++ -Wall ane.c FlashRuntimeExtensions.so -o aneObject
FlashRuntimeExtensions.so: could not read symbols: File in wrong format
collect2: ld gaf exit-status 1 terug
Your command line tries to generate x86 code and link it to ARM code using the native g++ available in your distribution.
This will not work. Use the Android NDK available here: http://developer.android.com/tools/sdk/ndk/index.html
The NDK includes a set of cross-toolchains (compilers, linkers, etc..) that can generate native ARM binaries on Linux, OS X, and Windows (with Cygwin) platforms.
In general .so will be linked using -l.
for example, pthread -lpthread we use.
gcc sample.c -o myoutput -lpthread
But as per #chill's statement, what you are doing in command is correct only.
I suggest you to refer the following link.
C++ Linker Error SDL Image - could not read symbols
It should be an architecture mismatch. I faced this problem once, I have solved it by building the libs in same target platform and it is obvious. If you are using linux or Unix like OS you can see that by file command and if you are using windows you can see that using Dependency Walker. You need to make sure that all the libs matches architecture.
While compiling my program which is using libevent library I am using gcc option -levent. But I am getting this error -
/usr/bin/ld: cannot find -levent
I do not have libevent on my system so I am statically linking to it while compiling using
gcc -o Hello -static -I libevent-1.4.12-stable/ hello.c -levent
How can i resolve this?
Thanks in advance!
Where is the libevent.(a|so) file on your system?
If it isn't on your system's library path then you will have to add a -L option adding its location to the list of paths searched by the linker for libraries.
e.g.
gcc -L/folder/containing/event/lib -levent mysource.cc
You need to have the libevent on your system or need to specify its path explicitly (if its a third-party library you got with the headers).
I suspect its not in your default /lib paths.