I've just written a Makefile to build a shared library, similar to the following:
libmystuff.so: CFLAGS+=-fPIC -shared
libmystuff.so: libmystuff.o otherstuff.o
$(CC) $(CFLAGS) -o $# $^
I like to avoid doing explicit actions when this seems like a common operation, but it seems there's no implicit rule or other built-ins to standardize this. I'm using GNU Make on Linux at the moment, but will need this to work on OS X as well.
EDIT: I'm asking about make rules rather than compiler/linker flags.
Can you recommend clean, reusable Makefile rules to build shared libs? Perhaps a %.so: or .c.so: type rule?
For portability, I'd look into integrating libtool.
define compile_rule
libtool --mode=compile \
$(CC) $(CFLAGS) $(CPPFLAGS) -c $<
endef
define link_rule
libtool --mode=link \
$(CC) $(LDFLAGS) -o $# $^ $(LDLIBS)
endef
LIBS = libmystuff.la
libmystuff_OBJS = libmystuff.lo otherstuff.lo
%.lo: %.c
$(call compile_rule)
libmystuff.la: $(libmystuff_OBJS)
$(call link_rule)
install/%.la: %.la
libtool --mode=install \
install -c $(notdir $#) $(libdir)/$(notdir $#)
install: $(addprefix install/,$(LIBS))
libtool --mode=finish $(libdir)
libtool will automatically add -fPIC/-DPIC/-shared flags as appropriate, and generate whatever .o/.a/.so files would be used on the current platform.
Or you could use Automake's libtool integration.
Building shared libraries is platform dependent. For example, the flags you are using are
ok for GCC for ELF platforms, for cygwin, for example, you do not add -fPIC for some other platforms and compilers you need other flags.
You need one of:
Provide an option to set flags for user platform.
Use standard build system like Autotools
Related
I have a problem trying to create a Makefile that compile multiple sorces, generate only a shared library and make an exe with another file wiht the main function.
The sorces also have dependencies.
My Makefile is
CC=gcc
CFLAGS=-Wall -g
BINS=libsensorMotor.so maintarget
all: $(BINS)
libsensorMotor.o: libsensorMotor.cpp sensorMotor.h Adafruit_ADS1015.cpp Adafruit_ADS1015.h wiringPiI2C.c wiringPiI2C.h enumADCGain.h
$(CC) $(CFLAGS) -c libsensorMotor.cpp Adafruit_ADS1015.cpp wiringPiI2C.c
libsensorMotor.so: libsensorMotor.cpp sensorMotor.h
$(CC) $(CFLAGS) -fPIC -shared -o $# libsensorMotor.cpp -lc
maintarget: maintarget.c
$(CC) $(CFLAGS) -o $# $^ -L. -lsensorMotor -pthread
clean:
rm *.o $(BINS)
The script show the errors:
libsensorMotor.so Undefined reference to 'functionXXXX'
maintarget contains the main and use libsensorMotor as a shared library. libsensorMotor depends and include all the rest of the files
The error mention all the functions that libsensorMotor uses from the include sources.
I only need to generate a correct libsensorMotor.so that can use as shared library from any other main file. Internet has many tutorials but are unclear, weird and complicated, and not show how do this simple.
Is not Makefile problem, simply the line
gcc -pthread -lm -o maintarget maintarget.c libsensorMotor.cpp Adafruit_ADS1015.cpp wiringPiI2C.c
sends same error, the compiler not recongnice the function inside the pthread_create while compile C and C++ with gcc
My Makefile contains an implicit rule override in the form of an explicit rule definition. However, make still invokes the default implicit rule.
This is on RHEL 6.3, GNU Make Version 3.81.
CPPFLAGS = -Wall -O2
DEPDIR = .d
DEPFLAGS = -MT "$# $(DEPDIR)/$*.d" -MMD -MP -MF $(DEPDIR)/$*.d
SRCS = $(wildcard *.cpp)
OBJS = $(SRCS:.cpp=.o)
%.o: %.cpp $(DEPDIR)/%.d
g++ -c $< $(CPPFLAGS) $(DEPFLAGS) -o $#
$(DEPDIR)/%.d: $(DEPDIR) ;
$(DEPDIR):
mkdir -p $#
include $(wildcard $(DEPDIR)/*.d)
.PHONY: clean clobber
clean:
rm -f *.o
rm -rf $(DEPDIR)
Invocation of 'make' outputs this:
[tlytle#tlytle-dev]$ make
g++ -Wall -O2 -c -o my_source.o my_source.cpp
Why is make invoking the default implicit rule for %.o files and not my explicit rule for %.o files defined in my Makefile?
You are not overriding the default rule for building .o files from .cpp files. In order to override it you'd need to define a new rule with identical target and prerequisites; your implicit rule has extra prerequisites, so you're just adding a new implicit rule that could build a .o file.
The rules for choosing implicit rules when multiple ones may match can be confusing.
The simplest thing to do is delete the builtin rule so that it's not available to be considered. You can do this by defining an implicit rule with the same target and prerequisites as the builtin rule, but no recipe:
%.o : %.cpp
Now make will have no choice but to use your implicit rule.
Note that GNU make 3.81 is really old. In newer versions of GNU make you can delete all the builtin rules to start by adding this to your makefile:
MAKEFLAGS += -r
I'd start from trying to run it with --no-builtin-rules to prove/disprove the theory about implicit/default (both are legit terms) rules being involved.
The manual says, that for an override to work both the target and prerequisites must match, and in your case it's not. Could be that.
I have a makefile which is supposed to compile a large number of source files into individual object files, then link them into a shared library.
The list of source files are stored in a variable, SOURCES. During the $(OBJECTS) target, where the object files are compiled, make runs the command $(CC) $(CFLAGS) -c $< -o $#, where $< is $(addprefix $(SRCPATH),$(SOURCES)).
This makes the command use the same source file for every object file, giving me a bunch of object files made from Time.cpp and causing the linker to give me a bunch of errors of functions that are already defined in every other object file. How can I get this makefile to work?
# Variable setup
# BUILD - Either Debug or Release, specify when running make
# ARCH - Either 32 or 64, specify when running make
# CC - The compiler
# INC - The include directories
# CFLAGS - Compiler flags to use
# LDFLAGS - Linker flags to use
# OBJDIR - Directory for .o files
# BINARY - Output file path
# SOURCES - Path to each individual source file
# OBJECTS - Object files
ifeq ($(and $(ARCH),$(BUILD)),)
$(error You have either not defined an architecture or build or both, please run "make BUILD=(DEBUG/RELEASE) ARCH=(32/64)")
endif
CC = g++
INC = -I../../include -I../../extlibs/headers -I../../extlibs/headers/libfreetype/linux
LDFLAGS = -lX11 -lGL -lGLEW -lfreetype -ljpeg -lopenal -lsndfile
CFLAGS = $(INC) -std=c++0x -fPIC -pthread -m$(ARCH)
OBJDIR = ./obj/$(BUILD)/$(ARCH)-bit
BINPATH = ./bin/$(BUILD)/$(ARCH)-bit
BINARY = $(BINPATH)/libTyrant$(ARCH).so
SRCPATH = ../../src/
SOURCES = System/Time.cpp System/Mutex.cpp System/Log.cpp System/Clock.cpp System/Sleep.cpp System/Unix/ClockImpl.cpp System/Unix/MutexImpl.cpp System/Unix/SleepImpl.cpp System/Unix/ThreadImpl.cpp System/Unix/ThreadLocalImpl.cpp System/Lock.cpp System/String.cpp System/ThreadLocal.cpp System/Thread.cpp Audio/SoundRecorder.cpp Audio/SoundBuffer.cpp Audio/SoundSource.cpp Audio/AudioDevice.cpp Audio/ALCheck.cpp Audio/Sound.cpp Audio/Music.cpp Audio/SoundFile.cpp Audio/SoundStream.cpp Audio/SoundBufferRecorder.cpp Audio/Listener.cpp Graphics/RectangleShape.cpp Graphics/VertexArray.cpp Graphics/Shader.cpp Graphics/ConvexShape.cpp Graphics/ImageLoader.cpp Graphics/Sprite.cpp Graphics/RenderTexture.cpp Graphics/BlendMode.cpp Graphics/Shape.cpp Graphics/CircleShape.cpp Graphics/TextureSaver.cpp Graphics/Vertex.cpp Graphics/RenderTextureImpl.cpp Graphics/Texture.cpp Graphics/Text.cpp Graphics/GLExtensions.cpp Graphics/Image.cpp Graphics/RenderTextureImplFBO.cpp Graphics/GLCheck.cpp Graphics/RenderTextureImplDefault.cpp Graphics/Color.cpp Graphics/Transformable.cpp Graphics/RenderTarget.cpp Graphics/Transform.cpp Graphics/View.cpp Graphics/RenderStates.cpp Graphics/RenderWindow.cpp Graphics/Font.cpp Window/JoystickManager.cpp Window/Joystick.cpp Window/Window.cpp Window/Keyboard.cpp Window/GlResource.cpp Window/Unix/JoystickImpl.cpp Window/Unix/WindowImplX11.cpp Window/Unix/GlxContext.cpp Window/Unix/Display.cpp Window/Unix/VideoModeImpl.cpp Window/Unix/InputImpl.cpp Window/VideoMode.cpp Window/Mouse.cpp Window/GlContext.cpp Window/Context.cpp Window/WindowImpl.cpp Network/Ftp.cpp Network/TcpListener.cpp Network/Packet.cpp Network/IpAddress.cpp Network/TcpSocket.cpp Network/Socket.cpp Network/Unix/SocketImpl.cpp Network/UdpSocket.cpp Network/SocketSelector.cpp Network/Http.cpp
OBJECTS = $(addprefix $(OBJDIR)/,$(SOURCES:.cpp=.o))
ifeq ($(BUILD),DEBUG)
CFLAGS := $(CFLAGS) -g -pg -Og
endif
ifeq ($(BUILD),RELEASE)
CFLAGS := $(CFLAGS) -s -O3
endif
all: clean $(addprefix $(SRCPATH),$(SOURCES)) $(BINARY)
$(BINARY): $(OBJECTS) $(BINPATH)
$(CC) $(LDFLAGS) $(OBJECTS) -shared -o $#
$(OBJECTS): $(addprefix $(SRCPATH),$(SOURCES)) $(OBJDIR)
$(CC) $(CFLAGS) -c $< -o $#
$(OBJDIR):
mkdir ./obj
mkdir ./obj/$(BUILD)
mkdir $#
mkdir $#/Audio
mkdir $#/Graphics
mkdir $#/Network
mkdir $#/Network/Unix
mkdir $#/System
mkdir $#/System/Unix
mkdir $#/Window
mkdir $#/Window/Unix
$(BINPATH):
mkdir ./bin
mkdir ./bin/$(BUILD)
mkdir $#
clean:
rm -rf bin
rm -rf obj
You have several problems here.
Suppose all of the source files were in the working directory, and that's where the object files belonged too. Instead of trying to build all of the objects with one command, you could build each object separately, with a pattern rule to cover them all:
%.o: %.cpp
$(CC) $(CFLAGS) -c $< -o $#
Then you could make the OBJECTS prerequisites of the library, and Make would handle it all:
$(BINARY): $(OBJECTS)
$(CC) $(LDFLAGS) $^ -shared -o $#
(Once you had that working, you might remember that Make already had built-in rules for things like building foo.o from foo.cpp, but never mind that for now.)
But in your build scheme you combine this with other problems: 1) you have source files in several different directories, and 2) you want to build the objects elsewhere, namely 3) in a directory tree that mirrors the source tree, 4) which you build on the fly.
Addressing all of those points would make for quite an involved answer. Which of them are you already comfortable with?
I've made it work, though it may not be optimal. My solution:
$(BINARY): $(SOURCES) $(BINPATH)
$(CC) $(LDFLAGS) $(OBJECTS) -shared -o $#
$(SOURCES): $(OBJDIR)
$(CC) $(CFLAGS) -c $(SRCPATH)$# -o $(patsubst %.cpp,%.o,$(OBJDIR)/$#)
Basically, I just switched the targets from the Object files to the source files, appended the source path to the target name for the input file, and appended the object directory to the target name while also using patsubst to change the file extension from .cpp to .o. The entire makefile is pretty hacked together, I'm aware of that, but it works and that's good enough for me for my first makefile.
I got an assignment to improve running time of some code. The only problem is, I can't even compile it to run it on my machine in the first place. Every time I try, it stops somewhere in the midst of compiling saying this:
"undefined reference to `boost::re_detail::put_mem_block(void*)'
collect2: ld returned 1 exit status make: * [cpu] Error 1"
This is how makefile looks:
SHELL = /bin/bash
OBJECTS = main.o atom.o molecule.o charges.o pdb.o asa.o amino.o chain.o addition.o string_operation.o pdb_peptide.o protein_chain.o residue_atom.o chain_residue.o residue_contact.o atom_grid.o circles.o atom_space_calculations.o
OBJDIR = obj
VPATH = src:src/ext:$(OBJDIR)
CFLAGS = -O3 -Wall -lm -lboost_regex -L/usr/local/boost/lib
HDIRS = src,src/ext,src/qt_redistributable, usr/lib, usr/local/lib, usr/local/lib/include/boost, /usr/local/lib/lib/
IOPTS = $(addprefix -I, $(HDIRS))
cpu : $(addprefix $(OBJDIR)/, $(OBJECTS) $(CPUOBJS))
g++ $(CFLAGS) -o mcpu $^
$(OBJDIR)/%.o : %.cpp
g++ $(CFLAGS) $(IOPTS) -c $< -o $#
clean :
rm obj/*.o $(PROG)
I'm using Linux Mint x64 and I have tried everything I googled out. Installed the whole boost library in usr/local/lib (for no obvious reason because it didn't help), tried to edit LD PATH (I'm very new to Linux and I have no idea if that went right) and lots of stuff, but this thing doesn't seem to go through. Any help appreciated.
One problem with your makefile happens when you link your program. As you can see in these questions with g++ the order of your arguments at link time is really important. You need to put your libraries after your object files. One easy way to solve would be separating your linker flags (LDFLAGS) from the compiler flags (CFLAGS), and then putting LDFLAGS after $^ (your object files) in the link command.
CFLAGS = -O3 -Wall
LDFLAGS = -L/usr/local/boost/lib -lm -lboost_regex
cpu : $(addprefix $(OBJDIR)/, $(OBJECTS) $(CPUOBJS))
g++ $(CFLAGS) -o mcpu $^ $(LDFLAGS)
$(OBJDIR)/%.o : %.cpp
g++ $(CFLAGS) $(IOPTS) -c $< -o $#
As can be seen in the Catalogue of Built-In Rules:
Linking a single object file
n is made automatically from n.o by running the linker (usually called
ld) via the C compiler. The precise recipe used is:
$(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)
and Variables Used by Implicit Rules:
LDFLAGS
Extra flags to give to compilers when they are supposed to invoke the linker,
ld, such as -L. Libraries (-lfoo) should be added to the LDLIBS variable
instead.
So in this case -lboost_regex should be set or added to LDLIBS, not LDFLAGS.
The cross-compiling of Lua, a test module, and a real-life module went OK, but when I load the real-life module on an appliance running uClinux, I get this error:
appliance::/var/tmp> ./lua -l dummy
Hello from dummy
Bye from dummy
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
appliance::/var/tmp> ./lua -l luasql.sqlite3
./lua: can't resolve symbol '_luaL_ref'
I don't have enough experience to know what the cause is, although Google seems to point to issues with shared libraries. Maybe the module expects some library, or some specific version of a library and it's not there?
Has someone seen this type of error before? How could I investigate?
Thank you.
Edit: Here are the config/Makefiles that I used to build Lua, SQLite3, and LuaSQL for SQLite3:
# cat /var/tmp/lua-5.1.4/src/Makefile
MYCFLAGS=
MYLDFLAGS=
MYLIBS=
export PATH:=$(PATH):/usr/src/baps/opt/uClinux/bfin-linux-uclibc/bin
TARGET_CROSS=bfin-linux-uclibc-
export CC=$(TARGET_CROSS)gcc
export STRIP=$(TARGET_CROSS)strip
export AR=$(TARGET_CROSS)ar rcu
export RANLIB=$(TARGET_CROSS)ranlib
export STAGING_DIR=/usr/src/baps/uClinux-dist/staging
export UCLINUX_LIB=/usr/src/baps/uClinux-dist/lib
export UCLINUX_ROOT_LIB=/usr/src/baps/uClinux-dist/root/lib
export CFLAGS=-O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I$(STAGING_DIR)/usr/include -DLUA_USE_POSIX -DLUA_USE_DLOPEN
export LDFLAGS= -L$(STAGING_DIR)/usr/lib -L$(UCLINUX_LIB) -L$(UCLINUX_ROOT_LIB) -ldl -lm
...
$(LUA_T): $(LUA_O) $(LUA_A)
$(CC) -o $# $(CFLAGS) $(LDFLAGS) $(LUA_O) $(LUA_A)
$(LUAC_T): $(LUAC_O) $(LUA_A)
$(CC) -o $# $(CFLAGS) $(LDFLAGS) $(LUAC_O) $(LUA_A)
...
generic:
$(MAKE) all
# cat /var/tmp/sqlite-amalgamation-3070400/Makefile
export PATH:=$(PATH):/usr/src/baps/opt/uClinux/bfin-linux-uclibc/bin
TARGET_CROSS=bfin-linux-uclibc-
export CC=$(TARGET_CROSS)gcc
export STRIP=$(TARGET_CROSS)strip
export AR=$(TARGET_CROSS)ar rcu
export RANLIB=$(TARGET_CROSS)ranlib
export CFLAGS=-O2 -Wall
libsqlite3.o:
$(CC) $(CFLAGS) -DSQLITE_THREADSAFE=0 -o $# -c sqlite3.c
# cat /var/tmp/luasql-2.1.1/config
...
LUA_INC= /var/tmp/lua-5.1.4/src
LIB_OPTION= -shared #for Linux
...
DRIVER_LIBS= /var/tmp/sqlite-amalgamation-3070400/libsqlite3.o
DRIVER_INCS= -I/var/tmp/sqlite-amalgamation-3070400
WARN= -Wall
INCS= -I$(LUA_INC)
CFLAGS= -O2 $(WARN) -I$(COMPAT_DIR) $(DRIVER_INCS) $(INCS) $(DEFS)
CC=/usr/src/baps/opt/uClinux/bfin-linux-uclibc/bin/bfin-linux-uclibc-gcc
LDFLAGS = -Wl,--trace,--print-map,--cref
# cat /var/tmp/luasql-2.1.1/Makefile
...
src/$(LIBNAME): $(OBJS)
$(CC) $(CFLAGS) $(LDFLAGS) -o $# $(OBJS) $(DRIVER_LIBS) $(LIB_OPTION)
Edit: After being told that it was most likely a linking issue, and after more reading and trial/error, I finally found what it was: When building Lua, the following options are required: "-Wl,-E"
I don't have any experience with lua, but in general I can say that when a symbol is "unresolved", this is an indication that the linker cannot find the symbol in any of the archive files or libraries it is told to link together. You will need to identify what library defines the symbol and include it in the link command, usually with a -l flag. You may also need to provide a -L flag giving the directory that includes this library. In your Makefile, you could add these flags to the LDFLAGS variable.
In addition to the above answer, if you are running on an appliance, you have to make sure that you are not linking against the includes or libs on your build system. Your development system $PATH variable may be pointing to local include files and libs. In addition, you need to make sure that the libs are in a usable location in the appliance, usually in /bin or /lib.
Here is one other reason, when you get errors like can't resolve symbol 'open64' or can't resolve symbol 'setrlimit64' - you might be using an app with the large file support on an environment that doesn't support it. Watch out for the __USE_FILE_OFFSET64 macro.
Try deleting this line:
export STRIP=$(TARGET_CROSS)strip