I have some C++ code on an openSuse platform that I need to compile to be executed on a different linux-based target. Part of the code is a dynamic library libfoo.so. I compile everything with make and then copy the compiled executable prog together with the libfoo.so to the target. When I then run the executable, I get some errors indicating the libfoo could not be initialized. I've tried everything I could find to tell the executable where it can find the libfoo.so but I still get the error.
Could anybody tell me what I am doing wrong here? I feel like it could be an error in the Makefile.
I am very new to C++ and using Makefiles in general, and on top of it all, the target runs kind of a proprietary linux version, so I cannot provide much information about it. I do have the appropriate compiler for it though.
My directory structure on the openSuse platform:
|src
|--Foolib
|----foolib.h
|----libfoo.so
|--Otherlib
|----otherlib.h
|----otherlib.hpp
|---+OtherlibSrcDirectory
|--bar.cpp
|--bar.h
|--Makefile
Directory structure on the target:
|program
|--libfoo.so
|--prog
My Makefile:
LIBS = -LFoolib -lfoo
INC = -I OtherLib -I Foolib
CXXFLAGS += -lpthread -std=c++11 -D_GLIBCXX_USE_NANOSLEEP $(INC)
LDFLAGS = '-Wl,-rpath,$$ORIGIN'
SRC_FILES = bar.cpp
OBJ = $(SRC_FILES:%.cpp=%.o)
prog: $(OBJ)
$(CXX) $(CXXFLAGS) $(LDFLAGS) $(LIBS) -o $# $^
%.o: %.cpp
$(CXX) $(CXXFLAGS) $(LIBS) -c $<
Basically, bar.h includes Foolib/foolib.h as well as Otherlib/OtherlibSrcDirectory and bar.cpp includes bar.h. Then some functions from foolib.h are called in bar.cpp and they return error values. If necessary I can provide some more insights into the code but I'll leave it out for now to keep it a bit shorter.
Any help would be highly appreciated!
Found my mistake.
libfoo.so was already on the target machine and it was located in the correct folder (/lib). My program had been able to find it without problems.
My mistake: I executed my program on the target machine without root permissions.
Without root permissions, I am not allowed to initialize Foolib.
sudo ./prog fixed everything.
Related
First of all, please, don't just tell me this is a duplicate. I know, but the many questions I've looked through have all been given far too specific answers to assist me, and quite frankly half of it went over my head. I'm very new to using Makefiles and I'm baffled by why mine isn't working.
I'm sure it's something painfully simple but please lend a hand, if you need any more information I'll be happy to try to find it, and bear with me because I'm doing all this from my phone because my university's IT department is run by apes. Currently, this is my Makefile:
Makefile for Assignment 1
finish : main.o
g++ -o finish main.o
main.o :
g++ -c -g -Wall main.cpp
clean :
del main.o
(Sorry, it's not being cooperative, I want to make clear that there is the necessary tab in front of the commands)
I'm running this on Windows 10, using a GNU compiler. From what I can see it looks exactly the same as the example Makefile we were provided, aside from filenames. I know I'm in the right directory, nothing is misspelled, the source file should exist cause I'm staring at it sitting next to the makefile. Those are the generic fixes I remember seeing.
The main.o command works perfectly and compiles the source file, but the other two just give me the error
make: *** No rule to make target 'finish/clean'. Stop.
I'm confused, annoyed, new to Makefiles and Stack Overflow and just looking for a helping hand. Any advice would be greatly appreciated.
I am pasting my example:
CC = g++
CFLAGS = -g
test.o: test.cpp
$(CC) $(CFLAGS) -c test.cpp
last.o: last.cpp
$(CC) $(CFLAGS) -c last.cpp
program: test.o last.o
$(CC) $(CFLAGS) -o program test.o last.o
clean:
$(RM) test.o last.o
I was facing similar issue, Try using $(RM) instead of "del"
I am trying to write what I thought would be quite a simple Makefile and I'm just baffled! I'm not a makefile writer, but I thought I understood them enough to be able to get a simple one working.
Okay, I have a small project in a directory and also in this directory is a libs directory containing many .c files. What I'm trying to do is write a makefile that will build the contents of the /libs directory into a static lib file in the /libs directory and then compile a few source files in the / directory and link it against the built .a file.
I'm sure someone's going to suggest "why not use cmake", but that's not answer I'm looking for (waves hand like a Jedi.. ehehehehe)
CC = gcc
CFLAGS = -Wall
SOURCES = lzx.c csum.c dirs.c listner.c tree.c
OBJECTS = $(SOURCES:.c=.o)
TARGETLIB = libs/mylib.a
TARGET = TestApp
libs/%.o : libs/%.c
$(CC) $CFLAGS -c $<
$(TARGETLIB) : $(OBJECTS)
ar rcs $# $^
$(TARGET) :
$(CC) $CFLAGS Source1.cpp Source2.cpp -llibs/mylib.a -o $#
My understanding was that the first recipe, would compile all the .c files into objects, but it seems to compile the first .c file and then stop.
Any help anyone could give me would be appreciated.
Since Your final app is TARGET, You should make it first Makefile rule. And since it also depends on TARGETLIB it should be given as dependency, like so:
$(TARGET): $(TARGETLIB)
$(CC) $(CFLAGS) Source1.cpp Source2.cpp -Lmylib -o $#
next I assume that *.c files You mentioned are lib files. Thus You will need a prefix to them, since You want to specify them by hand, not via wildcard or rule.
OBJECTS = $(addprefix(libs, $(SOURCES)):.c=.o)
and last thing that comes to my mind is library name, which supposed to be libSOMENAME.a (well, linker searches for this name in path and -Lotherpaths). So we have:
TARGETLIB = libs/libmylib.a
summing it all up:
CC = gcc
CFLAGS = -Wall
SOURCES = lzx.c csum.c dirs.c listner.c tree.c
OBJECTS = $(addprefix(libs, $(SOURCES)):.c=.o)
TARGETLIB = libs/libmylib.a
TARGET = TestApp
$(TARGET) : $(TARGETLIB)
$(CC) $(CFLAGS) Source1.cpp Source2.cpp -static -L./libs -lmylib -o $#
$(TARGETLIB) : $(OBJECTS)
ar rcs $# $^
And yes, this could be written much better, but I assume if You wanted to learn more about Makefiles or linker, and not just shown where You made mistakes, You'd know how to find manual pages.
Following is my directory structure
calculator
|
|---src
(multiply.cpp sum.cpp)
|---lib
I am building a static library calc.a using following
ar -rcs calc.a multiply.o sum.o
calc.a is builded in current directory.
I trying calc.a to be put into lib folder not in current directory (i.e. src)
I searched in internet and man page but couldn't find anything.
Any idea?
Since you are using the command line, the easiest way to write the library into the lib directory is to do it explicitly:
ar -rcs lib/libcalc.a multiply.o sum.o
Using a Makefile you can do more sophisticated things, but even then, it boils down to the same thing, e.g. adding the path to the front of the library name.
Since you asked for additional info on your comment, I add here a simple Makefile, which may be helpful to get you started:
CC=g++
CFLAGS=-c -Wall
LDFLAGS=
SOURCES=src/main.cpp src/sum.cpp src/multiply.cpp
OBJECTS=$(SOURCES:.cpp=.o)
LIBRARY=lib/libcalc.a
EXECUTABLE=main
all: $(SOURCES) $(LIBRARY) $(EXECUTABLE)
$(LIBRARY): $(OBJECTS)
<tab>mkdir -p lib
<tab>ar -rcs $# $<
$(EXECUTABLE): $(OBJECTS)
<tab>$(CC) $(LDFLAGS) $(OBJECTS) -o $#
.cpp.o:
<tab>$(CC) $(CFLAGS) $< -o $#
clean:
<tab>rm -rf main lib/ src/*.o
Important: All <tab>s must be replaced with real tabs, as required by the Makefile syntax!
Makefiles are very very flexible, so they can be very simple and specific to your problem, or as general and/or complex to build many libraries and binaries, based on millions and millions of source code. I suggest you to search for Makefile documentation for more information.
As a final note, I also suggest you to rename your library as 'libcalc.a', since the 'lib' prefix is standard in Unix. Other similar standards apply for other environments.
i am new to makefiles and have just rescently created a makefile that works for a c++ project. it has two cpp files and one h file. i am trying to convert my file to work in linux but cant seem to figure out how. any ideas?
EXE = NumberGuessingGame.exe
CC = cl
LD = cl
OBJ = game.obj userInterface.obj
STD_HEADERS = header.h
CFLAGS = /c
LDFLAGS = /Fe
$(EXE): $(OBJ)
$(LD) $(OBJ) $(LDFLAGS)$(EXE)
game.obj: game.cpp $(STD_HEADERS)
$(CC) game.cpp $(CFLAGS)
userInterface.obj: userInterface.cpp $(STD_HEADERS)
$(CC) userInterface.cpp $(CFLAGS)
#prepare for complete rebuild
clean:
del /q *.obj
del /q *.exe
For in depth treatment of make on Linux, see GNU make.
There are a few differences. Binaries have no extension
EXE = NumberGuessingGame
The compiler is gcc, but need not be named, because CC is built in, same goes for LD. But since your files are named .cpp, the appropriate compiler is g++, which is CXX in make.
Object files have extension .o
OBJ = game.o userInterface.o
STD_HEADERS = header.h
Compiler flags
CXXFLAGS = -c
The equivalent for /Fe is just -o, which is not specified as LDFLAGS, but spelled out on the linker command line.
Usually, you use the compiler for linking
$(EXE): $(OBJ)
$(CXX) $(LDFLAGS) $(OBJ) -o $(EXE)
You don't need to specify the rules for object creation, they are built in. Just specify the dependencies
game.o: $(STD_HEADERS)
userInterface.o: $(STD_HEADERS)
del is called rm
clean:
rm -f $(OBJ)
rm -f $(EXE)
One important point is, indentation is one tab character, no spaces. If you have spaces instead, make will complain about
*** missing separator. Stop.
or some other strange error.
You can also use CMake to accomplish your task:
Put following into CMakeLists.txt file in the root directory of your project (<project-dir>):
cmake_minimum_required (VERSION 2.6)
project (NumberGuessingGame)
add_executable(NumberGuessingGame game.cpp serInterface.cpp)
Then on the console do
"in-source" build
$ cd <project-dir>
$ cmake .
$ make
or "out-source" build
$ mkdir <build-dir>
$ cd <build-dir>
$ cmake <project-dir>
$ make
You can adjust build setting using nice GUI tool. Just go to the build directory and run cmake-gui.
You don't need to include headers in the dependency list. The compiler will fail on its own, stopping make from continuing. However, if you're including them in the dependency list to force make to rebuild files in case the header changes, nobody will stop you.
CFLAGS never needs to contain -c, nor does LDFLAGS need -o. Below is a revamped makefile. Note that you can always override a macro explicitly defined in a makefile or implicitly defined using something like make CFLAGS=-Wall for example. I used the de facto standard CXX macro name in the event that you have C source files, which must be compiled using a C compiler (the value of the CC macro) instead of a C++ compiler.
.POSIX:
#CC is already implicitly defined.
CXX = g++
OBJ = game.o userInterface.o
STD_HEADERS = header.h
.SUFFIXES:
.SUFFIXES: .o .cpp .c
NumberGuessingGame: $(OBJ) $(STD_HEADERS)
$(CXX) $(CFLAGS) -o $# $(OBJ) $(LDFLAGS)
.cpp.o: $(STD_HEADERS)
$(CXX) $(CFLAGS) -c $<
#There is already an implicit .c.o rule, thus there is no need for it here.
#prepare for complete rebuild
clean:
-rm -f NumberGuessingGame *.o
As yegorich answered, you can use a build system like Cmake. It is much more flexible, cross-platform, and can generate Unix Makefiles as well as Nmake Makefiles and Visual Studio solutions on Windows.
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