I ran into an issue with make. I have 3 files.
main.cpp | src/Math/Vector2.cpp | src/Math/Vector2.hpp
Here is my MakeFile:
main: vector2.o main.o
g++ -o main.o vector2.o
main.o: main.cpp
g++ -o main.o main.cpp -c
vector2.o: src/Math/Vector2.cpp src/Math/Vector2.hpp
g++ -o vector2.o src/Math/Vector2.cpp -lm -c
When i copy these commands manually , it compiles perfectly fine.
However $make main returns
g++ main.cpp -o main
/tmp/ccnRZ4UD.o: In function `main':
main.cpp:(.text+0x42): undefined reference to `
phy2d::Maths::Vector2f::Vector2f(double, double)'
main.cpp:(.text+0x66): undefined reference to `
phy2d::Maths::Vector2f::Vector2f(double, double)'
main.cpp:(.text+0x79): undefined reference to `
phy2d::Maths::Vector2f::distance(phy2d::Maths::Vector2f const&)
const'
collect2: error: ld returned 1 exit status
<builtin>: recipe for target 'main' failed
make: *** [main] Error 1
Any ideas??
There's no way that the makefile you provide will give the output you show.
In your comment you said Here is my MakeFile. Note that make will not read a file named MakeFile. It will read files named Makefile and makefile, but if you're using a case-sensitive filesystem then one explanation for the behavior you're seeing is that you've used MakeFile for your makefile name and make can't find it.
Or, you could have simply been imprecise in your question, but then this can't be the makefile that make is using for some other reason.
Also, there are numerous errors with your makefile:
You have two different targets main and main.o where the command generates the same file, -o main.o
You are adding libraries -lm to your compile line for vector2.o; libraries should go on the link line.
In general you should be using automatic variables to make sure your makefile is agreeing with what you want it to do.
Here's a reasonable makefile for your situation:
CXX = g++
main: vector2.o main.o
$(CXX) -o $# $^ -lm
main.o: main.cpp
$(CXX) -c -o $# $<
vector2.o: src/Math/Vector2.cpp src/Math/Vector2.hpp
$(CXX) -c -o $# $<
Related
I am programming a module for my Alderbaran Nao V5 robot. Alderbaran recommends using qibuild to compile a module, and I was able to successfully do so, but now I am trying to migrate towards writing my own makefile and using g++.
I am encountering the following error:
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../lib/crt1.o: In function
`_start':
(.text+0x18): undefined reference to `main'
/home/nao/naoqi-sdk-2.1.3.3-linux32/lib/libqimessaging.so: undefined reference to `std::__detail::_List_node_base::swap(std::__detail::_List_node_base&, std::__detail::_List_node_base&)#GLIBCXX_3.4.15'
/home/nao/naoqi-sdk-2.1.3.3-linux32/lib/libqi.so: undefined reference to `std::invalid_argument::~invalid_argument()#GLIBCXX_3.4.15'
/home/nao/naoqi-sdk-2.1.3.3-linux32/lib/libqitype.so: undefined reference to `std::out_of_range::~out_of_range()#GLIBCXX_3.4.15'
/home/nao/naoqi-sdk-2.1.3.3-linux32/lib/libqitype.so: undefined reference to `std::__detail::_List_node_base::_M_transfer(std::__detail::_List_node_base*, std::__detail::_List_node_base*)#GLIBCXX_3.4.15'
/home/nao/naoqi-sdk-2.1.3.3-linux32/lib/libqimessaging.so: undefined reference to `std::__detail::_List_node_base::_M_unhook()#GLIBCXX_3.4.15'
/home/nao/naoqi-sdk-2.1.3.3-linux32/lib/libqimessaging.so: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)#GLIBCXX_3.4.15'
/home/nao/naoqi-sdk-2.1.3.3-linux32/lib/libqi.so: undefined reference to `posix_spawnp#GLIBC_2.15'
collect2: ld returned 1 exit status
make: *** [shm.so] Error 1
Here is the makefile I am using:
#Variables
CXXFLAGS=-Wall -g
CXX = g++
NaoQi_INC = /home/nao/naoqi-sdk-2.1.3.3-linux32/include
NaoQi_LIB = -L/home/nao/naoqi-sdk-2.1.3.3-linux32/lib -lalcommon -lalerror -lalproxies -lalvalue -lqimessaging -lqitype -lqi
#Object Targets
main.o: main.cpp shm.h
$(CXX) $(CXXFLAGS) -c -I$(NaoQi_INC) main.cpp
shm.o: shm.cpp shm.h $(NaoQi_INC)/alcommon/alproxy.h $(NaoQi_INC)/alcommon/albroker.h $(NaoQi_INC)/alcommon/almodule.h
$(CXX) $(CXXFLAGS) -c -I$(NaoQi_INC) shm.cpp
#Library Targets
shm.so: main.o shm.o
$(CXX) $(CXXFLAGS) -o shm.so main.o shm.o -L/usr/local/lib -lm $(NaoQi_LIB)
clean:
rm -f *o main
rm -f *o shm
all: shm.o main.o shm.so
I noticed that the gentoo operating system I am compiling on has up to GLIBCXX_3.4.14 but does not have GLIBCXX_3.4.15. How can I fix this issue? Why would this issue not present itself when I build the module using qibuild?
Interestingly, the problem was that my .so linking command was missing a -shared flag. Not sure why that gave all of the errors I ran into, however.
I am trying to compile my C++ program using make and I've come across this problem that I can't quite understand. I have 3 files in the src folder of my project: App.h, App.cpp and main.cpp. I have my Makefile located in the root folder of my project, which has the src folder that I mentioned in it. This is what my Makefile looks like:
CC=g++
SRCDIR=./src
CFLAGS=-I$(SRCDIR)
LIBS=-lSDL -lGL
_DEPS=App.h
DEPS=$(patsubst %,$(SRCDIR)/%,$(_DEPS))
_OBJ=main.o App.o
OBJ=$(patsubst %,$(SRCDIR)/%,$(_OBJ))
_SRC=main.cpp App.cpp
SRC=$(patsubst %,$(SRCDIR)/%,$(_SRC))
%.o: $(SRC) $(DEPS)
$(CC) -c -o $# $< $(CFLAGS)
tetris: $(OBJ)
$(CC) -o $# $^ $(CFLAGS) $(LIBS)
clean:
rm -f $(SRCDIR)/*.o $(SRCDIR)/*~
When I type make into the terminal to compile, I get an error like this:
g++ -c -o src/main.o src/main.cpp -I./src
g++ -c -o src/App.o src/main.cpp -I./src
g++ -o tetris src/main.o src/App.o -I./src -lSDL -lGL
src/App.o: In function `main':
main.cpp:(.text+0x0): multiple definition of `main'
src/main.o:main.cpp:(.text+0x0): first defined here
src/main.o: In function `main':
main.cpp:(.text+0x17): undefined reference to `App::App()'
main.cpp:(.text+0x23): undefined reference to `App::onExecute()'
src/App.o: In function `main':
main.cpp:(.text+0x17): undefined reference to `App::App()'
main.cpp:(.text+0x23): undefined reference to `App::onExecute()'
collect2: error: ld returned 1 exit status
But I am sure that I only have 1 main function, and it is in the main.cpp file. What is causing this?
Look at these lines:
src/main.o: In function `main':
src/App.o: In function `main':
Those mean that main is defined both in main.o and App.o.
And above those:
g++ -c -o src/main.o src/main.cpp -I./src
g++ -c -o src/App.o src/main.cpp -I./src
See? Both object files are built using the same source!
You probably want to change this line for the object dependency:
%.o: %.c $(DEPS)
Look at the compilation lines.
You are compiling main.cpp as both main.o and App.o.
You are listing all your source files as prerequisites of the %.o pattern and using $< to only compile the first one (which happens to be main.cpp in this case.
You want %.c instead of $(SRC) there.
I am developing a little program with pocketsphinx (speech to text - library).
On Windows i was using Code::Blocks as development environment and i had success to build a program.
Now i try to port my program to Linux and i am having little problems to link against pocketsphinx.
This is the Makefile:
CC = g++
CFLAGS = -Wall -std=c++11
LDFLAGS = -I/usr/local/include/sphinxbase -I/usr/local/include/pocketsphinx
OBJ = obj/Application.o obj/Main.o obj/Recorder.o
all: $(OBJ)
$(CC) -L/usr/local/lib -o bin/Eve $(OBJ) -s -lsphinxbase -lpocketsphinx
obj/Main.o: src/Main.cpp
$(CC) $(CFLAGS) $(LDFLAGS) -c src/Main.cpp -o obj/Main.o
obj/Application.o: src/Application.cpp src/Application.hpp
$(CC) $(CFLAGS) $(LDFLAGS) -c src/Application.cpp -o obj/Application.o
obj/Recorder.o: src/Recorder.cpp src/Recorder.hpp
$(CC) $(CFLAGS) $(LDFLAGS) -c src/Recorder.cpp -o obj/Recorder.o
It is the same which i was using on Windows, i just adjusted the file path.
I am receiving the following error:
$ make
g++ -Wall -std=c++11 -I/usr/local/include/sphinxbase -I/usr/local/include/pocketsphinx -c src/Application.cpp -o obj/Application.o
g++ -Wall -std=c++11 -I/usr/local/include/sphinxbase -I/usr/local/include/pocketsphinx -c src/Main.cpp -o obj/Main.o
g++ -Wall -std=c++11 -I/usr/local/include/sphinxbase -I/usr/local/include/pocketsphinx -c src/Recorder.cpp -o obj/Recorder.o
g++ -L/usr/local/lib -o bin/Eve obj/Application.o obj/Main.o obj/Recorder.o -s -lsphinxbase -lpocketsphinx
obj/Recorder.o: In function `Recorder::Recorder()':
Recorder.cpp:(.text+0x1c0): undefined reference to `ad_open_sps'
Recorder.cpp:(.text+0x20d): undefined reference to `ad_read'
Recorder.cpp:(.text+0x215): undefined reference to `cont_ad_init'
obj/Recorder.o: In function `Recorder::~Recorder()':
Recorder.cpp:(.text+0x2f3): undefined reference to `cont_ad_close'
Recorder.cpp:(.text+0x303): undefined reference to `ad_close'
obj/Recorder.o: In function `Recorder::recognizeFromMicrophone()':
Recorder.cpp:(.text+0x37a): undefined reference to `ad_start_rec'
Recorder.cpp:(.text+0x395): undefined reference to `cont_ad_calib'
Recorder.cpp:(.text+0x3f0): undefined reference to `cont_ad_read'
Recorder.cpp:(.text+0x4e6): undefined reference to `cont_ad_read'
Recorder.cpp:(.text+0x5b5): undefined reference to `ad_stop_rec'
Recorder.cpp:(.text+0x5d8): undefined reference to `ad_read'
Recorder.cpp:(.text+0x5f4): undefined reference to `cont_ad_reset'
collect2: error: ld returned 1 exit status
make: *** [all] Fehler 1
I don't think that it is a name mangling problem, since i built the lib on my own using the provided Makefile.
What can i do to link against the lib without errors?
EDIT: I figured out how to make it work. I simply modified the rule of the target "all" to this:
$(CC) -static -L/usr/local/lib -o bin/Eve $(OBJ) -s -lpocketsphinx -lsphinxbase -lsphinxad -lpthread
Functions like ad_read are defined in libsphinxad library, you need to add it to your linker command line:
g++ -static -L/usr/local/lib -o bin/Eve obj/Application.o obj/Main.o obj/Recorder.o \
-lpocketsphinx -lsphinxbase -libsphinxad
Please note that the order of libraries is important.
When compiling a little C or C++ project in terminal using gcc, g++ or make, I get these kind of errors:
/tmp/ccG1caGi.o: In function `main':
main.c:(.text+0xa): undefined reference to `display_menu'
main.c:(.text+0xf): undefined reference to `get_input'
collect2: ld returned 1 exit status
main.c:
#include "menu.h"
int main()
{
display_menu();
get_input();
return 0;
}
menu.h:
void display_menu();
int get_input();
However with Xcode I get no errors or warnings.
What could be the issue here? It's seems it's like this when I include files.
So, gcc is complaining that it doesn't know where display_menu and get_input are, what they are doing or how to link them in, and rightly so.
You probably have more sourcefiles, where those functions are defined (menu.c, perhaps?). If so, add them to your compile instruction:
gcc main.c menu.c
Alternatively, just compile into an object (waiting for the functions later) with the -c flag. This will not make an executable, but will make an object file that awaits final compilation with
gcc main.c -c # Make the main.o object
gcc menu.c main.o # Link the main.o object with a compiled menu.c
into a final executable.
Xcode, in all likelihood, knows all about all your source files, and is happy to put them all together in its compilation step. If you are doing it manually, you have to do a little more work yourself. Its not when you include files (h files, that is) but when you have multi-file sources.
Try with a basic Makefile:
CC=gcc
CFLAGS=-W -Wall
LDFLAGS=
SRC= $(wildcard *.c)
OBJ= $(SRC:.c=.o)
all: myexec
myexec: $(OBJ)
#$(CC) -o $# $^ $(LDFLAGS)
%.o: %.c
#$(CC) -o $# -c $< $(CFLAGS)
.PHONY: clean
clean:
#rm -rf *.o
I compile one test code with g++ without any issue.
#include "Python.h"
int main(int argc, char** argv)
{
Py_Initialize();
PyRun_SimpleString("import pylab");
PyRun_SimpleString("pylab.plot(range(5))");
PyRun_SimpleString("pylab.show()");
Py_Exit(0);
}
g++ -o test test.cpp -I/usr/include/python2.7/ -lpython2.7
works fine and runs.
But when I try to embed this code into another project, it fails. It really confuses me.
Makefile is like the following.
CXX=g++
CXXFLAGS=-DIB_USE_STD_STRING -Wall -Wno-switch -g
ROOT_DIR=..
BASE_SRC_DIR=${ROOT_DIR}/PosixSocketClient
INCLUDES=-I${ROOT_DIR}/Shared/ -I${BASE_SRC_DIR} -I/usr/include/python2.7
LIBRARY=-L/usr/lib/python2.7/config
TARGET=eu
$(TARGET):
$(CXX) $(CXXFLAGS) $(INCLUDES) -o EClientSocketBase.o -c $(BASE_SRC_DIR)/EClientSocketBase.cpp
$(CXX) $(CXXFLAGS) $(INCLUDES) -o EPosixClientSocket.o -c $(BASE_SRC_DIR)/EPosixClientSocket.cpp
$(CXX) $(CXXFLAGS) $(INCLUDES) -o PosixTestClient.o -c PosixTestClient.cpp
$(CXX) $(CXXFLAGS) $(INCLUDES) -o Main.o -c Main.cpp
$(CXX) $(LIBRARY) -lpython2.7 -o $# EClientSocketBase.o EPosixClientSocket.o PosixTestClient.o Main.o
clean:
rm -f $(TARGET) *.o
This project compiles fine and runs, the only change I made was adding the test code in the Main.cpp file. warning/error message shows:
In file included from /usr/include/python2.7/Python.h:8:0,
from Main.cpp:15:
/usr/include/python2.7/pyconfig.h:1158:0: warning: "_POSIX_C_SOURCE" redefined [enabled by default]
/usr/include/features.h:163:0: note: this is the location of the previous definition
/usr/include/python2.7/pyconfig.h:1180:0: warning: "_XOPEN_SOURCE" redefined [enabled by default]
/usr/include/features.h:165:0: note: this is the location of the previous definition
g++ -L/usr/lib/ -lpython2.7 -ldl -lutil -o eu EClientSocketBase.o EPosixClientSocket.o PosixTestClient.o Main.o
Main.o: In function main':
/home/bbc/TWS/IBJts/cpp/eu-ats/Main.cpp:81: undefined reference toPy_Initialize'
/home/bbc/TWS/IBJts/cpp/eu-ats/Main.cpp:82: undefined reference to PyRun_SimpleStringFlags'
/home/bbc/TWS/IBJts/cpp/eu-ats/Main.cpp:83: undefined reference toPyRun_SimpleStringFlags'
/home/bbc/TWS/IBJts/cpp/eu-ats/Main.cpp:84: undefined reference to PyRun_SimpleStringFlags'
/home/bbc/TWS/IBJts/cpp/eu-ats/Main.cpp:85: undefined reference toPy_Exit'
collect2: ld returned 1 exit status
make: * [eu] Error 1
any help? thank you!
Take a look at Lucas's comment for the answer:
"To get rid of the _POSIX_C_SOURCE warning, make sure to include Python.h before all other header files."
I had the same problem. I use Boost Python, so for me I moved the include of boost/python.hpp to the first line in my .cpp file.
(Lukas, post your comment as an answer so the person who asked can mark it as the right answer, and the question won't remain 'unanswered' in StackOverflow.)
This is a bug in Python: https://bugs.python.org/issue1045893
If you include first Python.h, the compiler won't complain but GNU libc's /usr/include/features.h will override it anyway when _GNU_SOURCE is defined:
# undef _POSIX_C_SOURCE
# define _POSIX_C_SOURCE 200809L
# undef _XOPEN_SOURCE
# define _XOPEN_SOURCE 700