Linker can't find lib in Eclipse/JNI/ANT - c++

I am trying to build a large Java/c++ project involving JNI and ANT in Eclipse, under Linux. One of the source c++ files calls the log10() function for mathematical calculations. The project compiles fine, but fails at linking, where it complains that it cannot find the libm.so library necessary to link log10().
My problem is that I am unable to properly tell Eclipse to link that file, even after the following steps:
Added the correct library path in the linker options,
Added a reference to libm in the linker include list,
Added -lm to the full compile options list,
Set LD_LIBRARY_PATH to point to the library's location,
Copied the library to the current directory.
What am I doing wrong/has anyone had such experiences with correctly linking libs in Eclipse? Any suggestions?

This is a bit confusing.
If you fail to find your library at runtime inside your java environment :
Try loading your .so library inside the java environment before making any calls to log10.
System.LoadLibrary("m");
Notice how I left "lib" and ".so" out.
However, you are complaining of a Linker problem from C++, you cannot link to a dynamic file. You can only link to a static library, or a static export library (so you need a libm.a file to which to link at compile time, and then your program will require libm.so at runtime).
Could you post the exact message you are receiving and when you are receiving it ?

Related

Linking to SFML libraries without libsfml-dev

I currently have my Other Linker Options as:
Unfortunately, this means that I can only ever run the executable when libsfml-dev is installed, which is undesirable for game development. Whenever I even change the Other Linker Options or Search Directories>Linker will cause an error along the lines of:
error while loading shared libraries: libsfml-graphics.so.2.2.0: cannot open shared object file: No such file or directory. I assume this error happens because the libraries are relative, so it is completely portable.
EDIT:
I am using Code::Blocks (as you can see from the image), and I would like to know how I can link to the libraries relatively. They link fine when it is run from Code::Blocks, but when I run the executable I get the above error. My current Code::Blocks options are:
Linker Options:
(Other linker options is empty)
Search Directories:
Your first linker options would be the correct ones.
The Library libsfml-dev is only required on the compile machine.
There must also be another package which actually supplies the .so files. That one will also be required on the machine running the executable unless you package those .so files with your executable. In that case you probably need a script that sets LD_LIBRARY_PATH to the local directory containing the packaged .so files and then executes your program.

Include a static library in a static library - CodeBlocks

I'm having an issue compiling a static library using Code::Blocks 13.12. I need to use a third party static library from within my own static library. So, I have libOtherLib.a and I'm trying to build libMyLib.a and link in libOtherLib.a. The problem is that the linker is not including libOtherLib.a during the linking phase of the build. Here is some additional information:
I am using the GNU GCC Compiler
In Project build options for the whole project (not specifically Debug or Release)
I have added libOtherLib.a in the Link Libraries list in the Linker Settings
I have added the path to libOtherLib.a in the Search directories -> Linker list
I have added the path to the .h file for libOtherLib.a in the Search directories -> Compiler list
The library compiles completely fine (produces bin/Debug/libMyLib.a with no errors)
Any help would be greatly appreciated. I have an inkling that it is related to this being a Static Library rather than an application (console or otherwise), but I'm not sure how or why. I did change the build target Type to "Console Application" in the Project Properties window and it looked like it was linking in libOtherLib.a, but it had other errors because this code is meant to be a library rather than an application.
Here is the linker command that is executed at the end of the build. libOtherLib.a is not there anywhere, that is the problem, just not sure what the solution is.
ar -r -s bin/Debug/libMyLib.a <all of my .o files>
Possible causes of the problem would also be nice - if this is mostly like the compiler, the linker, the setup or Code::Blocks itself.
When building a static library you are just putting together a bunch of object files into an entity easier to ship and use. There is no linking done when building a static library.
The unresolved references from your library are dealt with when building an application or certain shared objects. You'd just ship your library and require that users also supply the library your library deoends on when building.
If you want to include the library you are depending on in your library you can extract the object files from tgat library and include them into your library. Although technically possible it is questionable if you have the rights to do so. Also, that is normally not the way things are done and I'd recommend against doing so.
You can't link a static library in anoter static library.
However,you can do this:
Suppose MyPrograme.exe need to link static library libMyLib.a,make MyPrograme.exe also link libOtherLib.a.
Since libMyLib.a is static library,there is no need to link libMyLib.a.Just inclue the headers.
When build a static library,it will only be compiled,not be linked.
Despite all this "linking is not the right term for this" philosophy, you can patch Code::Blocks compiler configuration to support this, for example for the GCC/G++ compiler.
http://green-candy.osdn.jp/codeblocks_config.html
The idea is that you replace the "Link object files to static library" script in the "Advanced compiler options" window of GCC with:
rm -f $static_output
$lib_linker -r -s -T $static_output $link_objects
$lib_linker -r -c -T $static_output $link_options
Then you can put the relative path to your "libOtherLib.a" in the "Other linker options" editbox of your projects. This mod is not really officially endorsed but it works in my projects, so you get static libs in static libs just like in MS Visual Studio!

How to add a library to Eclipse C

I have seen several other answers in order to add a library to my C+= project in eclipse.I have tried to add the path to the linker in Miscellaneous section using -L"and the path of the folder" and -l"the name without the lib prefix in the begging and the .so at the end"
I try to add libxl library so i use -lxl (for libxl.so) and -L/home/username/libxl3.5.3.0/lib/ (which the location of the lib file).
I have also tried to give it under the Linker menu and adding the name and the path in the Libraries section.
I get error that: /usr/bin/ld does not find -lxl file and it returns error
I am using -static to linker in order to make an executable that has the all the libs included but when i do not use -static the problem with the lib resolves from build but still when i try to run the program i get error that i the program can not open shared file libxl.so cause the file does not exist.How can i fix this?
When you add the library name to a C++ project in eclipse, do not prefix it with -l. Eclipse will do this for you when it invokes the compiler. For example if you want the boost_regex library, just input boost_regex not lboost_regex. Eclipse will do the rest for you. Or in your specific case, just use xl not lxl. You don't need the - either, nor the -L before paths as erenon points out in the comment below. Note that the above applies to the method of adding libraries using the Project->Properties->C/C++ General->Paths and Symbols dialog form for adding libraries using the Libraries and Library Paths tabs.
You are trying to link statically to a shared library. In my experience I have always used *.a files rather than *.so files to employ static linkage. This other answer Static link of shared library function in gcc seems to suggest that you are not actually able to link statically to *.so files.

g++ Linking vs VisualC++ Linking

I have been trying to get this working for a while now and am unable to find an answer elsewhere, here is my problem.
When I make a static library in Visual C++ any dependencies that this library uses are carried on to the executable program that I link the library to. Here is an example
Test.lib depends on
- SDL
- OpenGL
TestApp.exe links Test.lib
In Visual C++ I do not have to add the dependencies for Test.lib in my TestApp executable, they are carried over and it works great.
However when I port my code to Linux g++ (With the Code::Blocks IDE), if I make a Static Library which is .a in g++, and I make a TestApp that links the library, it gets undefined references to the dependencies.
Is g++ able to do this, and if so what am I missing to have the dependencies carried over to my executable?
As for my settings for my library I simply use the IDE's Static Library setting.
With Microsoft's compiler, header files can have library dependency information in them (source files, too, but this is typically done in headers); this gets compiled into the object file, and the linker understands and applies that information. That can be handy: you don't have to remember long, funky names, and if you compile two source files with incompatible options you may get a library name conflict that the linker will complain about. Most compilers and linkers don't do this kind of thing, and you have to tell the linker explicitly which libraries you want to link with.
Static libraries do not statically link with other libraries. Does that sound right?
However you can pack many object files together with a tool called ar.
What happens on windows is probably because you have the (SDL, opengl32) dlls somewhere in a system env path.

Statically linking to libarchive on Windows with MinGW

I've been using libarchive in my project for some time now and it's working great, at the moment I am dynamically linking to it, so on Windows the libarchive.dll file has to present on the system.
I would now like to statically link to the library so I don't have to bother distributing the DLL, but I'm having real trouble trying to achieve this!
Currently, in my make file, I have something like this:
-Lpath/to//libarchive/ -larchive
And this works, but it does a dynamic link. I don't know how to enforce a static link.
I can see in the libarchive directory there are two a files, libarchive.dll.a and libarchive_static.a. I suppose I want to link to libarchive_static.a but I can't seem to specify this, doing -larchive_static in the make file results in linker errors.
I was under the impression that static libraries under windows are lib files, but I get no such file type when I build libarchive.
How can I make a .lib file from libarchive. Also, as an extra question, what is the difference between an a file and a lib file?
Update
To statically link to libarchive, your library command for make should contain:
-Lpath/to//libarchive/ -larchive_static
This will link to the libarchive_static.a file. However, you also need to define LIBARCHIVE_STATIC in your code.
Now the problem is that libarchive depends on the bzip2 libraries (as well as others), and if you do not have a static build of them you will get linker errors something like:
undefined reference to `BZ2_bzCompressInit'
You need a static build of the dependent libraries and a similar command to the linker after the libarchive command:
-Lpath/to/bzip2/ -lbzip2
You can either build bzip2 from source, or do it the easy way and get a pre-built binary from the Gnu32Win project here: http://gnuwin32.sourceforge.net/packages.html
Just add libarchive_static.a explicitly to your link command.
gcc -o YourApp.exe $(OBJS) path/to/libarchive_static.a $(OtherLibs)
".lib" files differ from compiler to compiler (Borland, Microsoft etc.), ".a" is an old "archive" format from UNIX's ar tool. It is now used only for the bundling of static libraries.
Currently, in my make file, I have something ...
And this works, but it does a dynamic link
The .a file actually contains some code for dynamic linking to the .dll file, not the libarchive itself. On the startup the pointers to functions are allocated and dynamic linking is done.