I'm trying to create a shared library on ubuntu using gcc
I just have one simple class(shared.h and shared.cpp) and one client to use it (main.cpp)
This is my makefile and I'm still not able to to get the program to compile.
all:
#compile object(fPIC: creates position independent code)
gcc -fPIC -Wall -g -c shared.cpp
#compile shared library
gcc -shared -Wl,-soname,libshared.so.1 -o libshared.so.1.0.1 shared.o -lc
#link shared library
gcc -g -o main main.cpp -L. -lshared
I'm confident the first line is correct
I am unsure what "-lc" does. I think it passes something to the linker?
I don't want to install the library, I just want to be able to link it from the current directory. I have tried: export LD_LIBRARY_PATH=.
but it does not seem to make a difference. Everything is in the current directory.
ERROR: /usr/bin/ld: cannot find -lshared
how do I get the compiler to check the current directory for my library?
The problem is not that it's not looking in the directory, the problem is that you've named the library "libshared.so.1.0.1". When you use -lshared, it's looking for a file named 'libshared.so' or 'libshared.a' in the library search path.
Most of the time, when using versioned system libraries, you'll provide a link to the latest one as 'libshared.so', even if you have installed 'libshared.so.1' or 'libshared.so.1.0.1'.
In your case, if you continue to leave the file named 'libshared.so.1.0.1', you'll want to create 2 symbolic links:
libshared.so - So that the library can be found using ld
libshared.so.1 - Since you declared the SO name as libshared.so.1 when building it, you need to provide this link, otherwise, the executable will not be able to find the proper shared library at runtime.
You don't write any dependencies, which is the purpose of Makefile-s. And you probably need to force the run path Perhaps something like
.PHONY: all clean
CXX=g++
CXXFLAGS=-g -Wall
all: main
main: main.o libshared.so
$(LINK.cpp) -o $# $< -Wl,-rpath,. -L. -lshared
libshared.so: shared.pic.o
$(LINK.cpp) -shared -o $^ $<
main.o: main.cc shared.hh
%.pic.o: %.cc
$(CXX) $(CXXFLAGS) -fPIC -c -o $# $<
#
clean:
rm -f *.o *.so main *~
Related
I need to compile fat binary file to be able use it on another linux machine. But there are some libraries missing so as I understand I should compile it with some -shared options. But I don't understand how to configure a Makefile for that. Currently my makefile looks like this:
CC = g++
CC_FLAGS = -std=c++11 -O2 -static -Wall
EXEC = cpp_server
SOURCES = $(wildcard *.cpp)
OBJECTS = $(SOURCES:.cpp=.o)
LIBS = -lpthread -lmicrohttpd -lz
$(EXEC): $(OBJECTS)
$(CC) $(OBJECTS) -o $(EXEC) $(LIBS)
%.o: %.cpp
$(CC) -c $(CC_FLAGS) $< -o $#
clean:
rm -f $(EXEC) $(OBJECTS)
You'll better take advantage of the many built-in rules of GNU make. Run once make -p to learn them. So you should use CXX instead of CC and replace CC_FLAGS with CXXFLAGS.
You may want to build a statically linked executable. Then you should pass -static into your linking command, using LINKFLAGS
So try with
## untested Makefile for GNU make
# variables known to make
CXX= g++
CXXFLAGS= -std=c++11 -O2 -Wall -Wextra
LINKFLAGS= -static
LIBS= -lpthread -lmicrohttpd -lz
# this project needs:
MYEXEC= cpp_server
MYSOURCES= $(wildcard *.cpp)
MYOBJECTS= $(SOURCES:.cpp=.o)
.PHONY: all clean
all: $(MYEXEC)
$(MYEXEC): $(MYOBJECTS)
$(LINK.cc) $^ $(LOADLIBES) $(LDLIBS) -o $#
clean:
rm -f $(MYEXEC) $(MYOBJECTS)
AFAIK you don't need anything more in your Makefile (provided you use a GNU make, not e.g. a BSD one). Of course you need appropriate TAB characters in your Makefile (so you need to use some editor able to insert them).
You could want to statically link only -lmicrohttpd (and dynamically link the other libraries; however, you might want to also statically link the C++ standard library, which depends upon the compiler and could change when the compiler changes; linking also the C++ library statically is left as an exercise). You could do that with removing the LINKFLAGS line and using
LIBS= -Bstatic -lmicrohttpd -Bdynamic -lz -lpthread
BTW the -shared linker option is need to build from position-independent code object files a shared library (not to use one). See this and that.
You may want to use make --trace (or remake -x, using remake) to debug your Makefile
If you want to understand what actual files are linked, add -v -Wl,--verbose to LINKFLAGS perhaps by running make 'LINKFLAGS=-v -Wl,--verbose' on your terminal.
You might want to make clean before anything else.
I have some problems to use a custom shared library, since I get undefined reference errors for some functions from two of many other source files.
If I compile the whole project with main file (release:), everything works just fine. But if I create a shared library (lib:) and use this library with the main file (all:), those compile time errors occur.
Here is a snippet of my makefile
release:
$(CC) -Wall -s -w $(INCLUDES) $(LIBRARY) $(SRC) mainfile.cpp $(OCV) $(BOOST) $(GLOG) $(GFLAGS) -o test.exe
lib:
$(CC) -fPIC $(INCLUDES) $(LIBRARY) -c $(SRC) $(OCV) $(BOOST) $(GLOG) $(GFLAGS)
mv *.o obj/
$(CC) -shared -o libOutput.so obj/*.o
all:
$(CC) -Wall -s -w $(INCLUDES) $(LIBRARY) mainfile.cpp -L/path/to/lib/ -lOutput $(OCV) $(BOOST) $(GLOG) $(GFLAGS) -o project.exe
Since there is no error during compilation using the release-option, I'm assuming that there is a linker specific problem.
I inspected the specific object files using GNU Binary Utilities
nm -C obj/specific.o | grep functionName
with no results. I did the same for the shared library, but this time with the following result,
U functionName(std::vector<int>)
which means that the function is unknown.
Do you have any suggestions, how to fix this issue?
I have tried searching around other questions here on SO, but have still been unable to get my newly created C++ and .h linked to my main C file correctly. My implementation of my loader.cpp and loader.h are based off of this SO question.
My loader.cpp has no main function as I just want to use the C++ functions there. My shift.c file is where my int main() is located. Here is the basic structure of my loader.cpp file.
loader.cpp
#include "loader.h"
...
// Class Declaration
...
// Class implementation
I have been trying to compile with the following.
g++ loader.cpp -o obj -lGLU -lGL -lglut
The error I am getting here is...
(.text+0x20): undefined reference `to main'
So my two questions are, how do I get my cpp file to compile properly, and then what do I need to add to my Makefile to link them properly?
Makefile (for reference)
CC = gcc
CXX = g++
EXE = shift gears
# Main target
all: $(EXE)
CFLG=-O3 -Wall
LIBS=-lglut -lGLU -lGL -lm
CLEAN=rm -f $(EXE) *.o *.a
# Dependencies
gears.o: gears.c
shift.o: shift.c CSCIx229.h
fatal.o: fatal.c CSCIx229.h
loadtexbmp.o: loadtexbmp.c CSCIx229.h
print.o: print.c CSCIx229.h
project.o: project.c CSCIx229.h
errcheck.o: errcheck.c CSCIx229.h
object.o: object.c CSCIx229.h
# Create archive
CSCIx229.a:fatal.o loadtexbmp.o print.o project.o errcheck.o object.o
ar -rcs $# $^
# Compile rules
.c.o:
gcc -c $(CFLG) $<
.cpp.o:
g++ -c $(CFLG) $<
# Link
shift:shift.o CSCIx229.a
gcc -O3 -o $# $^ $(LIBS)
gears:gears.o
gcc -O3 -o $# $^ $(LIBS)
# Clean
clean:
$(CLEAN)
If you want g++ to compile an object module without linking it into a complete program then you must give it the -c option:
g++ -c loader.cpp -o loader.o
Note that that compilation command also assigns a conventional name to the generated object file, and that if you're not linking it into an executable then you don't need to specify libraries to link it to. Your Makefile is already set up for this.
If you add loader.o to the dependencies of CSCIx229.a then that should be enough to persuade make to build it from loader.cpp and to include the object file in your library (which will make it available for linking into your executables). You may also need to add some or all of -lGLU -lGL -lglut to your LIBS variable. It might also be appropriate to add loader.o's dependencies to the makefile if they include more than just loader.cpp itself (e.g. if they include CSCIx229.h).
Add the -c option to compile only. When you are ready to link the final application, then include all the object files and the list of libraries.
g++ -c loader.cpp -o loader.o
g++ loader.o (and the rest of your object files) -lGLU -lGL -lglut
Try adding this to your makefile:
shift:shift.o CSCIx229.a loader.o
gcc -O3 -o $# $^ $(LIBS)
I've been building a C++11 library, and the number of header/source files has grown to the point where compiling programs invoking it, entails passing 20+ .cpp files to g++. I've been reading up on shared libraries and it seems to be the best solution.
However, as headers/source change frequently, I'm hoping to create a makefile that would automatically generate all the .so files from the headers and source.
To better demonstrate what I'm trying to do, I'll take one of my sub-libraries, Chrono and show how I would do this manually.
I first create the object files like so,
$ g++ -std=c++11 -fPIC -g -c -Wall ../src/Chrono/cpp/DateTime.cpp
$ g++ -std=c++11 -fPIC -g -c -Wall ../src/Chrono/cpp/Schedule.cpp
$ g++ -std=c++11 -fPIC -g -c -Wall ../src/Chrono/cpp/Duration.cpp
$ g++ -std=c++11 -fPIC -g -c -Wall ../src/Chrono/cpp/DayCount.cpp
So that I now have DateTime.o, Schedule.o, Duration.o, and DayCount.o in the current directory. I then create the .so file,
$ g++ -shared -Wl,-soname,libChrono.so.1 -o libChrono.so.1.0.1 DateTime.o Schedule.o Duration.o DayCount.o -lc
I then go,
$ rm ./*.o && ldconfig -n ./
So that my working directory now contains, libChrono.so.1.0.1 and the symlink libChrono.so.1.
There are quite a few subdirectories I need to do this for, so you can see that this quickly grows inefficient whenever changes to headers/source are made. I would be grateful if anyone can help me design a makefile that accomplishes all this simply by invoking make.
Thanks!
UPDATE:
Based on goldilock's advice and some digging, I managed to bang together:
CXX=g++
CFLAGS=-std=c++11
TARGET=./lib/libChrono.so.1.0.1
CHRONODIR=./src/Chrono
CHRONOSRC=$(wildcard $(CHRONODIR)/cpp/*.cpp)
CHRONOOBJ=$(join $(addsuffix ../obj/, $(dir $(CHRONOSRC))), $(notdir (CHRONOSRC:.cpp=.o)))
all: $(TARGET)
#true
clean:
#-rm -f $(TARGET) $(CHRONOOBJ)
./lib/libChrono.so.1.0.1: $(CHRONOOBJ)
#echo "======================="
#echo "Creating library file $#"
#echo "======================="
#$(CXX) -shared -Wl,-soname,$(join $(basename $#), .1) -o $# $^ -l
#echo "-- $# file created --"
$(CHRONODIR)/cpp/../obj/%.o : $(CHRONOSRC)
#mkdir -p $(dir $#)
#echo "============="
#echo "Compiling $<"
#$(CXX) $(CFLAGS) -fPIC -g -Wall -c $< -o $#
4 .o files are produced in lib/ but I get multiple definition complaints from ld. Before I was compiling the object files separately, but this unwinds CHRONOOBJ on one line. Any ideas?
Fortunately you included the origin of your problem:
I've been building a C++11 library, and the number of header/source files has grown to the point where compiling programs invoking it, entails passing 20+ .cpp files to g++.
Because this reveals a potential XY problem. The straightforward solution to this is to put object files into an archive (aka. a static library) and use that.
GNU make has an implicit rule for creating C++ .o files. It amounts to this:
%.o: %.cpp
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $<
Meaning, if you make DateTime.o in a directory with a makefile that doesn't redefine this, it will make DateTime.o. You may want to add things to $(CXXFLAGS) however, e.g.:
CXXFLAGS += -Wall -Wextra --std=c++11
If you intend to stick with the shared lib route, -fPIC can go there too. That one line could be your entire makefile.
However, you also want to put these together, so you must first declare all the objects and a rule for combining them:
OBJS = DateTime.o Schedule.o Duration.o
libChrono.a: $(OBJS)
ar crvs $# $^
This last line (see man ar) creates the archive (libChrono.a) containing all the objects in $(OBJS). You can then use this with whatever program by placing it in the same directory (or a directory in the library path) and linking -lChrono. Only the necessary parts will be extracted and compiled in. This saves you having to maintain a shared lib in a system directory.
If you still think you need a shared lib, $# and $^ are automatic variables; you can use similar methodology to create a .so, something along the lines of:
SO_FLAGS = -shared
libChrono.so.1.0.1: $(OBJS)
$(CXX) $(SO_FLAGS) -Wl,-soname,libChrono.so.1 -o $# $^ -lc
If that is your first rule, make will take care of everything: building first the objects and then the library. Notice this one has excluded your normal $(CXXFLAGS) to duplicate exactly the compiler line from the question.
I am trying to compile the open-source AAM-library. I have tried in Visual Studio, and although it compiled, it had a run-time error. Now I'm trying to compile it in Ubuntu 11.04 using G++. The only makefile provided is a cygwin makefile. I am trying to use this to compile in Ubuntu. (I have included the makefile below). The problem I am having is near the bottom in the lines:
libaamlibrary.dll.a: $(OBJS)
g++ -fPIC -shared $(OBJS) $(LIBS) -o cygaamlibrary-2.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker libaamlibrary.dll.a
"--enable-auto-image-base" is not a recognised option. I am trying to rewrite these 3 lines to a form that does the same thing but works in Ubuntu, but I am struggling, because I don't really understand what the lines are doing (e.g., I don't understand Xlinker and how it should be used). Any advice would be much appreciated... Here is the full makefile for reference:
CPPFLAGS = -I. -I/home/andrew/MscProject/OpenCV-2.3.0/include/opencv -O2 -Wall -g -MD -fPIC
PROGRAMS = libaamlibrary.dll.a libaamlibrary.a fit build
LIBS = -L/usr/local/lib -lopencv_core -lopencv_imgproc -lopencv_highgui -lopencv_ml -lopencv_video -lopencv_features2d -lopencv_calib3d -lopencv_objdetect -lopencv_contrib -lopencv_legacy -lopencv_flann
OBJS = AAM_Util.o VJfacedetect.o AAM_Shape.o AAM_CAM.o AAM_PAW.o AAM_PDM.o AAM_TDM.o AAM_MovieAVI.o AAM_Basic.o AAM_IC.o
all: $(PROGRAMS)
AAM_Util.o: AAM_Util.cpp AAM_Util.h
g++ $(CPPFLAGS) -c -o AAM_Util.o AAM_Util.cpp
AAM_Shape.o: AAM_Shape.cpp AAM_Shape.h
g++ $(CPPFLAGS) -c -o AAM_Shape.o AAM_Shape.cpp
AAM_TDM.o: AAM_TDM.cpp AAM_TDM.h
g++ $(CPPFLAGS) -c -o AAM_TDM.o AAM_TDM.cpp
AAM_PDM.o: AAM_PDM.cpp AAM_PDM.h
g++ $(CPPFLAGS) -c -o AAM_PDM.o AAM_PDM.cpp
AAM_PAW.o: AAM_PAW.cpp AAM_PAW.h
g++ $(CPPFLAGS) -c -o AAM_PAW.o AAM_PAW.cpp
AAM_CAM.o: AAM_CAM.cpp AAM_CAM.h
g++ $(CPPFLAGS) -c -o AAM_CAM.o AAM_CAM.cpp
VJfacedetect.o: VJfacedetect.cpp VJfacedetect.h
g++ $(CPPFLAGS) -c -o VJfacedetect.o VJfacedetect.cpp
AAM_MovieAVI.o: AAM_MovieAVI.cpp AAM_MovieAVI.h
g++ $(CPPFLAGS) -c -o AAM_MovieAVI.o AAM_MovieAVI.cpp
AAM_Basic.o: AAM_Basic.cpp AAM_Basic.h
g++ $(CPPFLAGS) -c -o AAM_Basic.o AAM_Basic.cpp
AAM_IC.o: AAM_IC.cpp AAM_IC.h
g++ $(CPPFLAGS) -c -o AAM_IC.o AAM_IC.cpp
demo_build.o: train.cpp
g++ $(CPPFLAGS) -c -o demo_build.o train.cpp
demo_fit.o: fit.cpp
g++ $(CPPFLAGS) -c -o demo_fit.o fit.cpp
libaamlibrary.a: $(OBJS)
ar cru libaamlibrary.a $(OBJS)
ranlib libaamlibrary.a
libaamlibrary.dll.a: $(OBJS)
g++ -fPIC -shared $(OBJS) $(LIBS) -o cygaamlibrary-2.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker libaamlibrary.dll.a
fit: demo_fit.o
g++ -o fit demo_fit.o libaamlibrary.dll.a $(LIBS)
build: demo_build.o
g++ -o build demo_build.o libaamlibrary.dll.a $(LIBS)
clean:
rm -f *.o $(PROGRAMS)
I agree that you should not use a .dll.a or .dll extension (I believe .a and .so are appropriate), but it seems you can't do without libaamlibrary[.dll].a.
Since '--enable-auto-image-base' is prefixed with -Wl, this makes it a linker (ld) option.
I searched 'man ld' and came up with this:
--enable-auto-image-base
Automatically choose the image base for DLLs, unless one is
specified using the "--image-base" argument. By using a hash
generated from the dllname to create unique image bases for each
DLL, in-memory collisions and relocations which can delay program
execution are avoided. [This option is specific to the i386 PE
targeted port of the linker]
What is your platform? It is not available to non i386 architectures as I understand, and maybe not needed? So can you try compiling without it?
By the way I recommend using the excellent Autotools package (automake/autoconf/libtool).
Regarding --out-implib it is also not available on amd64.
--out-implib file
The linker will create the file file which will contain an import
lib corresponding to the DLL the linker is generating. This import
lib (which should be called ".dll.a" or ".a" may be used to link
clients against the generated DLL; this behaviour makes it possible
to skip a separate "dlltool" import library creation step. [This
option is specific to the i386 PE targeted port of the linker]
Sorry but I don't know what an import lib is.
Practical approach: first try building without all the .dll and .dll.a stuff; just remove the lines that refer to such targets.
It seems .dll.a files are static archives containing position-independent code (PIC), which are necessary in advanced linking scenarios, i.e. if you're developing shared libraries yourself. (Even if you want such a thing, you shouldn't call it .dll.a on Linux.)