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.
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'm getting some troubles with QT it builds with option "-lrt"
i'm using mac os 10.6 with QT creator 1.2.1, heeeeeeelp !
this is the full build command :
g++ -headerpad_max_install_names -o
AMiningCoreTest main.o tokenizer.o
DictionnaryToolBox.o mysql.o btree.o
BTreeDataTable.o tcaccess.o
-L/Library/Frameworks -L/usr/lib/mysql -lmysqlclient -L/usr/local/lib/ -ltokyocabinet -lz -lbz2 -lrt -lpthread -lm -lc
and it ends with
ld: library not found for -lrt
collect2: ld returned 1 exit status
The linker cannot find librt which is probably the Posix real time extensions library. I don't think this is available on OSX. Googling gives this from Apple developer lists
Question from list
I'm trying to build a simulator developed in my university (on Linux)
and I get error by the linker that seems unable to find librt.a - in
the code is used for clock_gettime() and I would like to know if
there's a port of such library, or some other similar function that
allows me to compile even on Mac OS X.
Answer
librt.a is the System V name of the library containing the POSIX
Advanced Realtime [RT} Option functions. The specific function you are
asking about is part of the [TMR] option. If Mac OS X supported it, it
would be in libSystem.B,dylib, not librt.a. The function in question
is not supported by Mac OS X.
Your code should check to see whether optional to implement things
above and beyond the UNIX standard are implemented in the target OS,
and if they aren't, use a different interface.
Why does the program need librt?
I know that some platforms (Solaris comes to mind) require librt for some functions which might exist in other libraries in your OS. (sem_init() et al. are like this)
You might try to link without -lrt and see if it works.
I have a virtual machine with ArchLinux installed. Here when I compile with GCC by running gcc file.c it gives me a shared library instead of an executable.
Later I find out that the problem is related only to GCC 7.2, in fact, when I compile with GCC 6.4, the output file is an executable.
How do I fix this?
The file utility is just incorrect in calling your program a shared library. It is a position-independent executable (PIE). If you really don't want this, you can specify -no-pie at link time, or build a gcc toolchain with --disable-default-pie, but in general you shouldn't need to change this.
To complement the answer that mentioned file as you pointed out in the comments, the default a.out generated by GCC is not a shared library but instead interpreted as a shared object by file maybe because of the content of your source code. Check this for more information.
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'm getting some troubles with QT it builds with option "-lrt"
i'm using mac os 10.6 with QT creator 1.2.1, heeeeeeelp !
this is the full build command :
g++ -headerpad_max_install_names -o
AMiningCoreTest main.o tokenizer.o
DictionnaryToolBox.o mysql.o btree.o
BTreeDataTable.o tcaccess.o
-L/Library/Frameworks -L/usr/lib/mysql -lmysqlclient -L/usr/local/lib/ -ltokyocabinet -lz -lbz2 -lrt -lpthread -lm -lc
and it ends with
ld: library not found for -lrt
collect2: ld returned 1 exit status
The linker cannot find librt which is probably the Posix real time extensions library. I don't think this is available on OSX. Googling gives this from Apple developer lists
Question from list
I'm trying to build a simulator developed in my university (on Linux)
and I get error by the linker that seems unable to find librt.a - in
the code is used for clock_gettime() and I would like to know if
there's a port of such library, or some other similar function that
allows me to compile even on Mac OS X.
Answer
librt.a is the System V name of the library containing the POSIX
Advanced Realtime [RT} Option functions. The specific function you are
asking about is part of the [TMR] option. If Mac OS X supported it, it
would be in libSystem.B,dylib, not librt.a. The function in question
is not supported by Mac OS X.
Your code should check to see whether optional to implement things
above and beyond the UNIX standard are implemented in the target OS,
and if they aren't, use a different interface.
Why does the program need librt?
I know that some platforms (Solaris comes to mind) require librt for some functions which might exist in other libraries in your OS. (sem_init() et al. are like this)
You might try to link without -lrt and see if it works.