Ok, I'm trying to build a makefile in order to compile a program on different environments. On Linux (Mint) it works just fine, but under Mac OS I get this error:
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [build] Error 1
With the '-v':
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix
"/Library/Developer/CommandLineTools/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.9.0 -w -o bin/Darwin/main ./cfprintf.o ./file.o ./inputmanager.o ./neditfile.o ./neditmanager.o ./neditscreen.o ./n_string.o ./sys_booter.o ./sys_display.o ./sys_manager.o ./sys_screen.o -lc++ -lSystem /Library/Developer/CommandLineTools/usr/bin/../lib/clang/5.1/lib/darwin/libclang_rt.osx.a
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [build] Error 1
Now here's the makefile:
CC = clang++
LIB =
INC = -I src/
OPTIONS = -w
OBJS = $(shell find ./src/obj -name '*.cpp')
IO = $(shell find ./src/io -name '*.cpp')
SYS = $(shell find ./src/sys -name '*.cpp')
APPS = $(shell find ./src/apps -name '*.cpp')
EXEC = bin/$(shell uname)/main
.PHONY: dummy build all objects io sys apps incBC clear run
build: clear incBC objects io sys apps
#echo "-> Compiling main... "
#$(CC) -c src/main.cpp $(INC) $(OPTIONS)
#echo "-> Building environment... "
#$(CC) $(shell find . -name '*.o') $(LIB) $(OPTIONS) -o $(EXEC) -v
#echo "-> Removing all objects file from compilation... "
#rm *.o
objects:
#echo "-> Building objects files and classes... "
#$(CC) -c $(OBJS) $(INC) $(OPTIONS)
io:
#echo "-> Building input/output files and classes..."
#$(CC) -c $(IO) $(INC) $(OPTIONS)
sys:
#echo "-> Building system files and classes..."
#$(CC) -c $(SYS) $(INC) $(OPTIONS)
apps:
#echo "-> Building all apps files and classes..."
#$(CC) -c $(APPS) $(INC) $(OPTIONS)
incBC:
#echo "-> Updated build count..."
#./incBC.sh
clear:
clear
run:
cd bin/$(shell uname)/ && clear && ./main
Now what's (al least to me) really weird, is that when I type make it fails one out of two times... LITERALLY one out of two! And when it does fail, I get the error message above. What I've noticed from that message is that, in the ld command, there is no main.o which is probably why I get the undefined reference. My question is: why? Why specifically one out of two times, and how can I fix this?
This is a bizarre makefile. Why not just write a shell script? There's nothing in this makefile that takes any advantage of make itself: it will always rebuild everything every time. The point of writing a makefile, instead of a shell script, is so you can avoid rebuilding objects that haven't changes.
Anyway, the reason you're seeing failures is that you're using make's $(shell ...) function inside of a recipe. This is not necessary, because a recipe is already running in a shell. The reason this fails for you is that make will expand the entire recipe (all lines) first, before it starts your recipe (it has to do this obviously). That means that because you're using $(shell ...) that find command is run before the recipe runs, and before the recipe runs you haven't compiled your main.o, so the find command doesn't include it in the list of object files found. Then the next time you run it, main.o exists from the previous run so the find command finds it.
Change this line:
#$(CC) $(shell find . -name '*.o') $(LIB) $(OPTIONS) -o $(EXEC) -v
to this:
#$(CC) `find . -name '*.o'` $(LIB) $(OPTIONS) -o $(EXEC) -v
and it will work.
Although it's still not very useful as a makefile.
Related
Following the readme for the installation, I'm stuck on point 5. After changing the path of z3, I get different errors when I execute 'make'.
ld: library not found for -lcrt0.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I've found this thread that specifies this kind of error. It seems that it's impossible to solve the error since, the use of 'static'. I report the message from the the thread:
This option will not work on Mac OS X unless all libraries (including libgcc.a)
have also been compiled with -static. Since neither a static version of libSystem.dylib
nor crt0.o are provided, this option is not useful to most people.
This is the Makefile that I used.
Z3_path = /Users/mat/z3
JUNK = str
SOURCE = *.cpp
INCLUDE = $(Z3_path)/lib
LIB = $(Z3_path)/bin/external
all: $(SOURCE)
#echo ">> Z3 Source Dir: "$(Z3_path)
#echo ""
g++ -O3 -std=c++11 -I$(INCLUDE) -L$(LIB) $(SOURCE) -lz3 -o str -Wall
#echo ""
clean:
rm -f $(JUNK)
I am using clang and boost 1.57 on OSX Yosemite. I am trying to create a dylib for a python application (used swig to make the wrappers). I have successfully compiled this code for Windows and Linux, so I know it is the build/link phase on OSX that is causing me issues. Here is my makefile (which is wrong, somehow):
CC=clang++
vpath %.c ./
vpath %.h ./
SRCS=RecorderLib.cpp RecorderLib_wrap.cpp
OBJS=$(SRCS:.cpp=.o)
LIBS= -lpython2.7 -lboost_iostreams-mt -lboost_system-mt -lboost_thread-mt -lboost_date_time-mt -lboost_chrono-mt -lboost\
_filesystem-mt -lboost_regex-mt -lboost_atomic-mt -lboost_serialization-mt -lboost_program_options-mt
CFLAGS=-arch x86_64 -Xarch_x86_64 -mmacosx-version-min=10.5 -pipe -O2 -c -stdlib=libstdc++
LINKFLAGS = -dynamiclib -undefined suppress -flat_namespace
.PHONY: RecorderLib64.dylib
all: RecorderLib_wrap.o RecorderLib.o RecorderLib64.dylib
RecorderLib_wrap.o:
$(CC) RecorderLib_wrap.cpp $(CFLAGS) $(LIBS) -o RecorderLib_wrap.o
RecorderLib.o:
$(CC) RecorderLib.cpp $(CFLAGS) $(LIBS) -o RecorderLib.o
RecorderLib64.dylib:
$(CC) $(LINKFLAGS) $(OBJS) $(LIBS) \
-o RecorderLib64.dylib
mv RecorderLib64.dylib ../../
clean:
rm *.o
If I remove the -undefined suppress -flat_namespace flags, the thing will toss me a million symbol not found for architecture x86_64 errors for all the boost functions that I reference.
When I include those flags, the library compiles but when I fire up the host application I get an error such as
OSError: dlopen(/Users/myself/RecorderApp/src/RecorderLib64.dylib, 6): Symbol not found: __ZN5boost9iostreams15file_descriptor4seekElSt12_Ios_Seekdir
which I interpret to mean the dylib doesn't know about boost.
One other thing that I don't understand, but is possibly related, is that when I compile the source objects, it tosses me errors such as:
clang: warning: -lpython2.7: 'linker' input unused
On linux, you want to link to libraries both at the compile stage and the link stage (at least this is my understanding -- in any case my Makefile.gnu which I am basing this off of does this and works beautifully).
I should also mention that I can compile applications on this system that link to boost and various dylibs and they work perfectly, so I know my boost installation etc. is alright. Also, inspecting the libraries I link to with the file command tells me they are of the correct x86_64 architecture.
Later:
So, I realize now that the symbol(s) not found for architecture x86_64 errors were actually pointing to functions in the stdlib (but were referenced from boost), i.e.:
"std::basic_streambuf<char, std::char_traits<char> >::setbuf(char*, long)", referenced from:
vtable for boost::iostreams::stream_buffer<boost::iostreams::file_descriptor_sink, std::char_traits<char>, std::allocator<char>, boost::iostreams::output> in RecorderLib.o
Changing the makefile so that the min osx version is 10.7 and using -stdlib=libc++ gets rid of all theses errors, but I am still getting symbol(s) not found for a boost:iostreams call:
"boost::iostreams::file_descriptor::seek(long,std::__1::ios_base::seekdir)"
In my code I make reference this pugixml like this:
#include "pugi/pugixml.hpp"
When compiling I get this error:
main in main-bf0b72.o
"pugi::xml_node::children(char const*) const", referenced from:
_main in main-bf0b72.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: *** [main] Error 1
From another question I was told to pugi as an additional translation unit and link them accordingly like this in my Makefile:
CC = g++
CFLAGS = -g -Wall -std=c++11
SRC = src
INCLUDES = include
TARGET = main
all: $(TARGET)
$(TARGET): $(SRC)/$(TARGET).cpp pugi/pugixml.cpp
$(CC) $(CFLAGS) -I $(INCLUDES) -o $# $^
clean:
$(RM) $(TARGET)
However when I try to run my Makefile after this change I get this error:
make: *** No rule to make target `pugi/pugixml.cpp', needed by `main'. Stop.
I'm really not sure what I am meant to be doing. Should pugi have it's own Makefile to build it individually, or should I give it is't own "target" in my Makefile?
Edit
This is my file system:
root/Makefile
root/src/main.cpp
root/include/pugi/pugixml.hpp
root/include/pugi/pugixml.cpp
root/include/pugi/pugiconfig.hpp
In your Makefile you try to compile pugi/pugixml.cpp file, but on filesystem it located in include/pugi/pugixml.cpp (relatively to Makefile itself). You should:
Create root/pugi directory and put pugixml.cpp file there
OR
Or replace pugi/pugixml.cpp with include/pugi/pugixml.cpp in your Makefile (but keeping source files in include/ subdirectory is bad idea).
I have a problem with getting compiled an wxWidget-application. I have installed the latest version of the library as follows:
set arch_flags="-arch x86_64 "
./configure -with-osx_cocoa --disable-shared --disable-compat24 --enable-unicode --enable-universal-binary CFLAGS="$arch_flags" CXXFLAGS="$arch_flags" CPPFLAGS="$arch_flags" LDFLAGS="$arch_flags" OBJCFLAGS="$arch_flags" OBJCXXFLAGS="$arch_flags"
sudo make install
I'am trying to compile a simple hello-world example with:
WXWIDGETS = -I/usr/local/include/wx-2.9/
CXXFLAGS = -O2 -g -Wall -Wextra -fmessage-length=0
CXX = $(shell wx-config --cxx)
PROGRAM = wxProjectExample
OBJECTS = $(PROGRAM).o
# implementation
.SUFFIXES: .o .cpp
.cpp.o :
$(CXX) -c `wx-config --static=yes --libs` `wx-config --static=yes --cxxflags` -o $# $<
all: $(PROGRAM)
$(PROGRAM): $(OBJECTS)
$(CXX) -o $(PROGRAM) $(OBJECTS) `wx-config --libs`
clean:
rm -f *.o $(PROGRAM)
But the compilation fails while linking with:
ld: warning: in /System/Library/Frameworks//QuickTime.framework/QuickTime, missing required architecture x86_64 in file
ld: warning: in /usr/lib/libwx_macud-2.8.dylib, missing required architecture x86_64 in file
Undefined symbols:
"wxWindowBase::DoSetVirtualSize(int, int)", referenced from:
vtable for MyFramein wxProjectExample.o
Where could be a problem or have somebody had similar problems with this framework?
Thx.
PS
System: SnowLeopard (64 bit) 10.6.5. with an intel proc, gcc 4.2.
i fixed this problem by adding the path to the new wx-binaries to PATH
$ export PATH=/usr/local/Cellar/wxmac/2.8.11/bin:$PATH
i'm using brew to install wxmac.
I'm surprised that you have libwx_xxx in /usr/lib when the default installation prefix is /usr/local. Are you sure you don't have multiple incompatible libraries versions on your system?
Also, when using static linking the libraries containing the dependencies of your code must come after the object file referencing them so the wx-config --libs part should be at the end of your rule.
I recently got MySQL compiled and working on Cygwin, and got a simple test example from online to verify that it worked. The test example compiled and ran successfully.
However, when incorporating MySQL in a hobby project of mine it isn't compiling which I believe is due to how the Makefile is setup, I have no experience with Makefiles and after reading tutorials about them, I have a better grasp but still can't get it working correctly.
When I try and compile my hobby project I recieve errors such as:
Obj/Database.o:Database.cpp:(.text+0x492): undefined reference to `_mysql_insert_id'
Obj/Database.o:Database.cpp:(.text+0x4c1): undefined reference to `_mysql_affected_rows'
collect2: ld returned 1 exit status
make[1]: *** [build] Error 1
make: *** [all] Error 2
Here is my Makefile, it worked with compiling and building the source before I attempted to put in MySQL support into the project. The LIBMYSQL paths are correct, verified by 'mysql_config'.
COMPILER = g++
WARNING1 = -Wall -Werror -Wformat-security -Winline -Wshadow -Wpointer-arith
WARNING2 = -Wcast-align -Wcast-qual -Wredundant-decls
LIBMYSQL = -I/usr/local/include/mysql -L/usr/local/lib/mysql -lmysqlclient
DEBUGGER = -g3
OPTIMISE = -O
C_FLAGS = $(OPTIMISE) $(DEBUGGER) $(WARNING1) $(WARNING2) -export-dynamic $(LIBMYSQL)
L_FLAGS = -lz -lm -lpthread -lcrypt $(LIBMYSQL)
OBJ_DIR = Obj/
SRC_DIR = Source/
MUD_EXE = project
MUD_DIR = TestP/
LOG_DIR = $(MUD_DIR)Files/Logs/
ECHOCMD = echo -e
L_GREEN = \e[1;32m
L_WHITE = \e[1;37m
L_BLUE = \e[1;34m
L_RED = \e[1;31m
L_NRM = \e[0;00m
DATE = `date +%d-%m-%Y`
FILES = $(wildcard $(SRC_DIR)*.cpp)
C_FILES = $(sort $(FILES))
O_FILES = $(patsubst $(SRC_DIR)%.cpp, $(OBJ_DIR)%.o, $(C_FILES))
all:
#$(ECHOCMD) " Compiling $(L_RED)$(MUD_EXE)$(L_NRM).";
#$(MAKE) -s build
build: $(O_FILES)
#rm -f $(MUD_EXE)
$(COMPILER) -o $(MUD_EXE) $(L_FLAGS) $(O_FILES)
#echo " Finished Compiling $(MUD_EXE).";
#chmod g+w $(MUD_EXE)
#chmod a+x $(MUD_EXE)
#chmod g+w $(O_FILES)
$(OBJ_DIR)%.o: $(SRC_DIR)%.cpp
#echo " Compiling $#";
$(COMPILER) -c $(C_FLAGS) $< -o $#
.cpp.o:
$(COMPILER) -c $(C_FLAGS) $<
clean:
#echo " Complete compile on $(MUD_EXE).";
#rm -f $(OBJ_DIR)*.o $(MUD_EXE)
#$(MAKE) -s build
I like the functionality of the Makefile, instead of spitting out all the arguments etc, it just spits out the "Compiling [Filename]" etc.
If I add -c to the L_FLAGS then it compiles (I think) but instead spits out stuff like:
g++: Obj/Database.o: linker input file unused because linking not done
After a full day of trying and research on google, I'm no closer to solving my problem, so I come to you guys to see if you can explain to me why all this is happening and if possible, steps to solve.
Regards,
Steve
Try changing
$(COMPILER) -o $(MUD_EXE) $(L_FLAGS) $(O_FILES)
to
$(COMPILER) -o $(MUD_EXE) $(O_FILES) $(L_FLAGS)
The linker searches and processes libraries and object files in the order they are specified. Thus when you mention the libraries before the object files, the functions used in the object files may not be loaded from the libraries.
Have you tried using the built-in mysql_config --cflags and mysql_config --libs, respectively?