I have the following files:
.
├── combinatorics
│ ├── permutation.cpp
│ └── permutation.h
├── main.cpp
└── math
├── basic.cpp
└── basic.h
and am trying to create a shared library by doing these steps:
g++ -c -Wall -std=c++14 -fpic combinatorics/permutation.cpp -o permutations.o
g++ -c -Wall -std=c++14 -fpic math/basic.cpp -o mathbasic.o
g++ -shared -o combmath.so permutations.o mathbasic.o
g++ -Wall -std=c++14 main.cpp -L. -o output -lcombmath
but I am getting the following message:
/usr/bin/ld: cannot find -lcombmath
collect2: error: ld returned 1 exit status
what am I doing wrong?
The linkage option -lfoo directs the linker to search for a file
libfoo.so (shared library) or libfoo.a (static library) in the specified
linker search directories (-L/x/y/z) and then in the linker's default
search directories, stopping when it finds either one of those files and
preferring libfoo.so if it finds both in the same directory.
For your linkage:
g++ -Wall -std=c++14 main.cpp -L. -o output -lcombmath
to succeed, therefore, you need previously to have built libcombmath.so
in the same directory with the command:
g++ -shared -o libcombmath.so permutations.o mathbasic.o
and not built combmath.so, as you have done with the command:
g++ -shared -o combmath.so permutations.o mathbasic.o
Related
I have a source file, mything.cpp, and a library that was provided to me as notmine.h and notmine.a.
I need to produce a shared object that has all my stuff from mything.cpp and all the stuff from somelib.a. Here is what I did on the command line:
g++ -fpic -c -o mything.o mything.cpp
g++ -shared -o mything.so mything.o notmine.a
However, when I look at the final mything.so using ldd I see that it has a dependency on libnotmine.so, and when I check nm, I see that all the symbols that should have been supplied by notmine.a are undefined.
What am I doing wrong?
More details: notmine.a is actually liblua.a that I built locally. I think g++ might be getting confused because there is a liblua.so in the system directories
Finally figured it out. There are two options. The simpler is to use:
g++ -fpic -c -o mything.o mything.cpp
g++ -shared -o mything.so mything.o -L. -l:notmine.a
Alternatively, you can tell the linker you want to treat the .a as a bunch of object files with
g++ -fpic -c -o mything.o mything.cpp
g++ -shared -o mything.so mything.o -Wl,--whole_archive notmine.a -Wl,--no-whole-archive
The --Wl,-no-whole-archive is to prevent that flag from messing up the other steps the linker does with the system libraries
I wanted to learn how to make a shared library in C++. So I found some logic to generate Mandelbrot PPM images, and encapsulated it in src/mandelbrot.cpp (with accompanying header file include/mandelbrot.cpp). Directory tree looks like:
$ tree
.
├── Makefile
├── include
│ └── mandelbrot.h
├── lib
│ └── mandelbrot.dylib
└── src
├── client.cpp
├── main
├── main.cpp
├── mandelbrot.cpp
└── mandelbrot.o
The goal is for src/client.cpp to use lib/mandelbrot.dylib to draw the fractal without having access to src/mandelbrot.cpp or src/mandelbrot.o.
Makefile:
.PHONY=clean
main: src/mandelbrot.o
clang++ src/main.cpp -o src/main src/mandelbrot.o -I ./include
src/mandelbrot.o:
clang++ -c src/mandelbrot.cpp -o src/mandelbrot.o -I ./include
clean:
rm src/*.o
rm lib/*.dylib
lib/mandelbrot.dylib:
clang++ -dynamiclib -o lib/mandelbrot.dylib src/mandelbrot.cpp -I ./include
src/client: lib/mandelbrot.dylib
clang++ src/client.cpp -o src/client -L ./lib -I ./include
Running the executable without the dylib works:
$ make main
clang++ src/main.cpp -o src/main src/mandelbrot.o -I ./include
$ ./src/main # runs fine!
But I can't get my shared library to link when compiling src/client.cpp:
$ make src/client
clang++ src/client.cpp -o src/client -L ./lib -I ./include
Undefined symbols for architecture x86_64:
"fractal::Mandelbrot::writeToFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)", referenced from:
_main in client-e344c7.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [src/client] Error 1
Even though the symbol seems to be in the dylib:
$ file lib/mandelbrot.dylib
lib/mandelbrot.dylib: Mach-O 64-bit dynamically linked shared library x86_64
$ nm -C lib/mandelbrot.dylib | grep writeToFile
0000000000001460 T fractal::Mandelbrot::writeToFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)
I'm trying to dig in deeper and understand the linking/compilation process. How do I make the setup I have work to demonstrate what I want to do?
Try naming your library like libmandelbrot.dylib to match the -lmandelbrot flag
Credit goes to #Daniel for finding the answer, but a bit about why.
I can make the compilation work by renaming mandelbrot.dylib -> libmandelbrot.dylib as suggested by #daniel's answer.
I dug into man ld (the linker) and found the following definition:
-lx This option tells the linker to search for libx.dylib or libx.a in the library search path. If string x is of the form y.o, then that file is searched for in the same places, but without prepending
`lib' or appending `.a' or `.dylib' to the filename.
Thus, if you want to arbitrarily name your dynamically loaded libraries (and for some reason don't like the magic of prepending libxxxx to the name, you'd have to do this (I have confirmed this works):
lib/whatever.o:
clang++ -dynamiclib -o lib/whatever.o src/mandelbrot.cpp -I ./include
src/client: lib/whatever.o
clang++ src/client.cpp -o src/client -L ./lib -I ./include -l whatever.o
TL;DR = By having the -l option as a filename ending in .o, the linker looks directly in the directory specified by -L for the exact filename specified in -l. Otherwise -l foo -L /path/ searches for /path/libfoo.[dylib|a]
I'm currently trying to use a makefile to automate my build process which I am still new to. When I run the g++ command:
g++ -I includes -L lib -lSDL2_test -lSDL2 -lSDL2main main.o -o main.exe
from the following makefile:
main: main.o
g++ -I includes -L lib -lSDL2_test -lSDL2 -lSDL2main main.o -o main.exe
main.o: main.cpp
g++ -c main.cpp
I get clang: error: linker command failed with exit code 1
However when running the same g++ command from the same directory as the makefile everything compiles correctly and I don't get the error. So how do I fix this?
EDIT:
I've done some testing and found out the problem with the makefile is that the -I includes g++ flag is not enabling the main.o file to find SDL.H, hopefully that helps to narrow down the problem.
#G.M's comment isn't unrelated - it's the correct answer to the problem. The include files are needed during the compile stage (the main.o: main.cpp rule), NOT during the link stage (i.e. the main: main.o rule.)
Move the -I includes flag to the second rule, and try again.
I am trying to use GLEW in a program I'm creating, but my compiler will not compile it, instead it throws a ton of errors at this line gcc -g -c glew.c -o glew.o. This is my Makefile:
MY_LIBS =
glewex: glew.o main.o glew.h
g++ main.o glew.o glew.h -o glewex $(MY_LIBS)
glew.o: glew.c
gcc -g -c glew.c -o glew.o
main.o: main.cpp
g++ -g -c main.cpp -o main.o
It simply outputs hundreds of errors that look like this:
__glewActiveTexture redeclared without dllimport attribute: previous import ignored [ -Wattributes ]
Try this:
gcc -g -DGLEW_STATIC -c glew.c -o glew.o
That should prevent DLL import/export decorations from getting added to the declarations.
You don't want to add the library source files to the compiler input of your project. You should add the library to the list of linker inputs; either statically (libglew.a) or dynamic (-lglew).
I.e. either
gcc -o … -lglew
or
gcc -o … libglew.a
When linking GLEW statically you must add -DGLEW_STATIC to the compiler options generating the compilation units (.o files)
[SOLVED] created symlinks from /usr/lib/lib/* to /usr/lib*
[UPDATE 3] NEW VERSION:
Ok, I think I fixed something
use find / -name "libboost_system.*"
outout was
/usr/include/boost/lib/libboost_system.so
/usr/include/boost/lib/libboost_system.a
/usr/include/boost/lib/libboost_system.so.1.46.1
/usr/lib/lib/libboost_system.so
/usr/lib/lib/libboost_system.a
/usr/lib/lib/libboost_system.so.1.46.1
/usr/local/include/boost_1_46_1/bin.v2/libs/system/build/gcc-4.4.3/release/link-static/threading-multi/libboost_system.a
/usr/local/include/boost_1_46_1/bin.v2/libs/system/build/gcc-4.4.3/release/threading-multi/libboost_system.so.1.46.1
/usr/local/lib/libboost_system.so
/usr/local/lib/libboost_system.a
/usr/local/lib/libboost_system.so.1.46.1
/root/tmp/boost_1_46_1/bin.v2/libs/system/build/gcc-4.4.3/release/link-static/threading-multi/libboost_system.a
/root/tmp/boost_1_46_1/bin.v2/libs/system/build/gcc-4.4.3/release/threading-multi/libboost_system.so.1.46.1
why are these files in /usr/lib/lib ? and is it a problem ?
and the ls -l /usr/lib/lib | grep boost_system
ls -l /usr/lib/lib | grep boost_system
-rw-r--r-- 1 root root 21574 2011-05-09 15:15 libboost_system.a
lrwxrwxrwx 1 root root 25 2011-05-09 15:15 libboost_system.so -> libboost_system.so.1.46.1
-rwxr-xr-x 1 root root 20053 2011-05-09 15:15 libboost_system.so.1.46.1
atm my makefile looks like
LIBPATH=-I/usr/local/include/cpp-netlib
LIBS=$(LIBPATH) -lboost_system -lboost_filesystem -lboost_thread -lpthread
LD=g++ -g
CPP=g++ -c -g $(LIBS)
P=.
OBJ=$(P)/tmp/main.o $(P)/tmp/CLink.o $(P)/tmp/CFetcher.o
main: $(OBJ); $(LD) $(OBJ) $(LIBS) -o $#
$(P)/tmp/CLink.o: $(P)/src/CLink.cpp $(P)/include/CLink.h; $(CPP) -c $< -o $#
$(P)/tmp/CFetcher.o: $(P)/src/CFetcher.cpp $(P)/include/CFetcher.h; $(CPP) -c $< -o $#
$(P)/tmp/main.o: $(P)/src/main.cpp $(P)/include/CLink.h $(P)/include/CFetcher.h ; $(CPP) -c $< -o $#
all:
touch $(P)/tmp/*.o;
touch main;
rm -f $(P)/tmp/*.o;
rm -f main;
make main;
The Compiler output is lie
g++ -c -g -I/usr/local/include/cpp-netlib -lboost_system -lboost_filesystem -lboost_thread -lpthread -c src/main.cpp -o tmp/main.o
g++ -c -g -I/usr/local/include/cpp-netlib -lboost_system -lboost_filesystem -lboost_thread -lpthread -c src/CLink.cpp -o tmp/CLink.o
g++ -c -g -I/usr/local/include/cpp-netlib -lboost_system -lboost_filesystem -lboost_thread -lpthread -c src/CFetcher.cpp -o tmp/CFetcher.o
g++ -g ./tmp/main.o ./tmp/CLink.o ./tmp/CFetcher.o -I/usr/local/include/cpp-netlib -lboost_system -lboost_filesystem -lboost_thread -lpthread -o main
So for me all looks nice but when i try to run the program
./main
./main: error while loading shared libraries: libboost_system.so.1.46.1: cannot open shared object file: No such file or directory
The -l flags must come after the source files on linker command-line.
Yes, that means you'll have to split the LD definition to LD and LIBS, put all the -L and -l flags in the later and change the link command to:
$(LD) $(OBJ) $(LIBS) -o $#
The library (.so (dynamic) or .a (static)) files have to be the same version as the headers. While there are boost 1.46.1 headers installed in /usr/local/include/boost_1_46_1/, the corresponding library files don't seem to be installed at all. The only installed libraries are version 1.40.0 in /usr/lib, so the linker finds those (/usr/lib would be searched by default even if you didn't include the -L/usr/lib flag), but they don't contain the symbols expected by 1.46.1.
Note that when linking against shared library (using shared libraries is strongly recommended in Linux), the linker looks for the file with .so extension, but that is usually symlink to a file with added version suffix and the linker reads it and records the target name in the binary. That way programs compiled against the .1.40 will continue to work when 1.46 is installed, because the libboost*.so.1.40.0 may (and have to) stay around after the .so is redirected to the 1.46.1 version.
It should be even possible to install like:
/usr/local/lib/boost_1_46_1/libboost_system-mt.so -> /usr/local/lib/libboost_system-mt.so.1.46
/usr/local/lib/libboost_system-mt.so.1.46 -> /usr/local/lib/libboost_system-mt.so.1.46.1
/usr/local/lib/libboost_system-mt.so.1.46.1
and compile using -L/usr/local/lib/boost_1_46_1, though I currently can't find any package that would do it to confirm this. This way you could have development files for multiple versions installed and switch between them using explicit -I and -L flags while dynamic linker would still find the runtime files, for which it only looks in /usr/local/lib, /usr/lib and /lib (it can be configured in /etc/ld.so.conf, but that's the default).
Execute your application with strace. This will show the location were you app is looking for your boost libs. In my case an app was looking in /usr/lib/x86_64-linux-gnu for boost libs where the actual location was /usr/lib/lib. A simple export statement adding the paths for the boost shared libs in my case LD_LIBRARY_PATH=/usr/lib/lib worked a treat.
output from strace
open("/usr/lib/x86_64-linux-gnu/libboost_system.so.1.46.1", O_RDONLY) = -1 ENOENT (No such file or directory)
exit_group(127) = ?