In Ubuntu 12.04.1 LTS I created a .so library file using this code:
g++ -c -Wall -Werror -fPIC someCode.cpp
g++ -shared -o libSomeCode.so someCode.o
I need to use that library file within an executable. But when running the .exe it cannot find the .so file. So I have to copy the library to /usr/lib/. I tried using this command (without success):
export LD_LIBRARY_PATH=/home/personalFolder/Desktop/codeFolder:$LD_LIBRARY_PATH
Is there a way to avoid copying the .so to /usr/lib/?
Thanks in advance.
Adding "; \" solved my problem.
Related
I want to use a shared library (resides in a custom directory) into an executable.
I've created this makefile
all: SayHello
SayHello: compiledObjects/SayHello.o myLib/libNames.so
g++ compiledObjects/SayHello.o -o SayHello -Icommons -LmyLib -lNames
compiledObjects/SayHello.o: SayHello.cpp
g++ -c SayHello.cpp -o compiledObjects/SayHello.o
myLib/libNames.so: commons/Names.cpp commons/Names.h
g++ -shared -fPIC commons/Names.cpp -o myLib/libNames.so
That create correctly the executable and shared library infact I can Execute the program using this command
LD_LIBRARY_PATH=/custom/path/to/lib/myLib/libNames.so
./SayHello
How can I execute ./SayHello without specify LD_LIBRARY_PATH?
I'm not using any IDE and I'm on linux.
Use the -rpath option to link your executable. See the ld(1) manual page for more information.
P.S. Your makefile appears to have a bug. If you successfully make your program, and immediately run make again, looks like your makefile will attempt to recompile the program again, even though nothing has changed.
After all, the whole purpose of a makefile is to avoid doing unneeded compilations.
The SayHello.o build target should be compiledObjects/SayHello.o.
You need to tell g++ to pass the -rpath option to the linker using -Wl,-rpath. Also, you need to specify a path to the -rpath option.
Putting it all together your last build step should look like this:
SayHello: compiledObjects/SayHello.o myLib/libNames.so
g++ compiledObjects/SayHello.o -o SayHello -Icommons -LmyLib -lNames -Wl,-rpath=/custom/path/to/lib/myLib/
Relative RPATH:
If you want to specify an RPATH relative to your binary you should use
$ORIGIN as a placeholder: -rpath='$ORIGIN/rel/path'.
I know that it is possible to make .dylib files with g++ compiler on the MacOSX platform. I want to make a .framework grouping headers and library. Is it possible to use g++ compiler for that? If not is there any command line interface tool for that purpose? (I want to avoid using xCode if possible)
I know you said you wanted to avoid using Xcode, but here is a nice link https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/CreatingFrameworks.html Follow the instructions ONLY for creating the framework, you'll get a .framework file. With the .framework file that you can place anywhere in your computer, you can compile outside of Xcode like so.
if in your current directory:
cwd=$(pwd)
g++ -Wall somefiles.c -o run "-I $(pwd)/some/path/name.framework -F $(pwd)/some/path/ -framework name"
otherwise
g++ -Wall somefiles.c -o run "-I /full/path/name/name.framework -F /full/path/name/ -framework name"
So I had successfully been using cmake and boost in my project.
I wanted to start incorporating armadillo (4.400.1)
I use enivronment modules (http://modules.sourceforge.net/) on my system.
I built with gcc-4.8.1.
CentOS 6.4.
I installed OpenBLAS (0.2.10) and armadillo from source and created environment modules.
In the past I only needed to prepend LD_LIBRARY_PATH with lib directories, but this was not sufficient for armadillo, as I was getting linking errors (unable to find lib) for the following:
g++ example1.cpp -o example1 -O2 -larmadillo
Using the -L option works:
g++ example1.cpp -o example1 -O2 -larmadillo -L${ARMADILLO_HOME}/lib
I am already placing the armadillo lib directory in LD_LIBRARY_PATH. How do I set environment variables so the following will link without error?
g++ example1.cpp -o example1 -O2 -larmadillo
I had to place the armadillo lib directory in the environment variable LIBRARY_PATH not LD_LIBRARY_PATH
Doing this allowed the linking to proceed without error when issuing the command:
g++ example1.cpp -o example1 -O2 -larmadillo
I am making a simple hello world program to learn about linking shared libraries in linux. I have managed to compile the main program into an executable with the shared library using the following:
g++ -fPIC -c lab2_hello_main.cpp <--create position independent objects
g++ -fPIC -c lab2_hello_sub.cpp
g++ -fPIC -shared -Wl,-soname=libfuncs.so.1.0 *.o -o libfuncs.so.1.0 -lc <--make the shared library
ln -s libfuncs.so.1.0 libfuncs.so <-- soft links for compiling and running
ln -s libfuncs.so.1.0 libfuncs.so.1
g++ -o hello_dyn lab2_hello_main.cpp -L/mypath -lfuncs <-- Linking the library to main
When I do an ldd on hello_dyn I get an output stating that the library can't be found:
"libfuncs.so.1.0 => not found"
The other libraries it looks for automatically are fine.
Anyone know why this might be?
Your shared library's location is not in the linker's search path. You can confirm this by adding the directory in which your library is located to the LD_LIBRARY_PATH environment variable and then run ldd again. See the ld.so(8) man page for details.
I am trying to get mingw gcc to work.
I need it to link with libopengl32.a.
Said file exists in C:/mingw/lib.
I used g++ as follows:
g++ -L"C:/mingw/lib" main.o -o test.exe -llibopengl32.a
It has no trouble finding the includes, it just complains that it can't find the library.
It seems unable to find any other library as well.
Also: I installed all the mingw components manually by downloading them from sourceforge, since using the automatic installer produced a broken installation on my system.
The -l flag automatically adds the lib prefix and the .a extension- you want:
g++ -LC:/mingw/lib main.o -o test.exe -lopengl32
Note you don't need the quotes around the path either. You could also just specify the whole library name & path:
g++ main.o -o test.exe C:/mingw/lib/libopengl32.a
As regards your installation problems, use either http://tdragon.net/recentgcc/ or http://nuwen.net/mingw.html - using the MinGW site itself is a recipe for pain.
You need to use -lopengl32 without "lib" and ".a"