I have some code that I use a (old) Mersenne Twister header file with to get a good pseudo-random number generator.
The problem is that that code uses the register keyword which (as far as I understand) was deprecated in c++11 and throws an error with c++17. I believe I am using the latter in the version of clang I'm using on Mac OSX (10.14.6; Mojave).
The Makefile I am using is as thus:
BUILDDIR=$(TOPDIR)/bin
INCDIROUT=$(BUILDDIR)/include
LIBDIROUT=$(BUILDDIR)/lib
INCDIR=inc/
SRCDIR=src/
INCFLAG= -IMersenne -Iinc
LIBFLAG= -L. -L$(LIBDIROUT)
#need to use an older version of gcc b/c of Mersenne Twister using the deprecated `register` keyword
#https://github.com/danini/graph-cut-ransac/issues/23
CXX=clang++
#CXXFLAGS=-g -std=c++11 -Wall -pedantic
CXXFLAGS=-fpermissive -std=c++98
#trick for getting the git version in the code
GIT_VERSION = $(shell sh -c 'git describe --abbrev=4 --always')
CFLAGS += -D__GIT_VERSION=\"$(GIT_VERSION)\"
RUN_SCRIPT := $(shell mkdir -p 'bin/lib')
all: $(BUILDDIR)/realizeCascades $(LIBDIROUT)/rootUtil.o $(LIBDIROUT)/edepmath.o $(LIBDIROUT)/cascadeProd.o $(LIBDIROUT)/isotope_info.o $(LIBDIROUT)/weisskopf.o $(LIBDIROUT)/lindhard.o $(LIBDIROUT)/libncap.so
$(LIBDIROUT)/isotope_info.o: $(SRCDIR)/isotope_info.c $(INCDIR)/isotope_info.h
$(CXX) -std=c++98 -fPIC -c $(CFLAGS) $(INCFLAG) $(SRCDIR)/isotope_info.c `root-config --cflags --glibs` $(LIBFLAG)
mv isotope_info.o $(LIBDIROUT)/
$(LIBDIROUT)/rootUtil.o: $(SRCDIR)/rootUtil.c $(INCDIR)/rootUtil.h
$(CXX) -std=c++98 -fPIC -c $(CFLAGS) $(INCFLAG) $(SRCDIR)/rootUtil.c `root-config --cflags --glibs` $(LIBFLAG)
mv rootUtil.o $(LIBDIROUT)/
$(LIBDIROUT)/edepmath.o: $(SRCDIR)/edepmath.c $(INCDIR)/edepmath.h
$(CXX) -std=c++98 -fPIC -c $(CFLAGS) $(INCFLAG) $(SRCDIR)/edepmath.c `root-config --cflags --glibs` $(LIBFLAG)
mv edepmath.o $(LIBDIROUT)/
$(LIBDIROUT)/weisskopf.o: $(SRCDIR)/weisskopf.c $(INCDIR)/weisskopf.h
$(CXX) -std=c++98 -fPIC -c $(CFLAGS) $(INCFLAG) $(SRCDIR)/weisskopf.c `root-config --cflags --glibs` $(LIBFLAG)
mv weisskopf.o $(LIBDIROUT)/
$(LIBDIROUT)/lindhard.o: $(SRCDIR)/lindhard.c $(INCDIR)/lindhard.h
$(CXX) -std=c++98 -fPIC -c $(CFLAGS) $(INCFLAG) $(SRCDIR)/lindhard.c `root-config --cflags --glibs` $(LIBFLAG)
mv lindhard.o $(LIBDIROUT)/
$(LIBDIROUT)/cascadeProd.o: $(SRCDIR)/cascadeProd.c $(INCDIR)/cascadeProd.h
$(CXX) -std=c++98 -fPIC -c $(CFLAGS) $(INCFLAG) $(SRCDIR)/cascadeProd.c `root-config --cflags --glibs` $(LIBFLAG)
mv cascadeProd.o $(LIBDIROUT)/
$(LIBDIROUT)/libncap.so: $(LIBDIROUT)/isotope_info.o $(LIBDIROUT)/weisskopf.o $(LIBDIROUT)/lindhard.o $(LIBDIROUT)/cascadeProd.o $(LIBDIROUT)/edepmath.o $(LIBDIROUT)/rootUtil.o
$(CXX) -std=c++98 -fPIC -shared $(LIBDIROUT)/lindhard.o $(LIBDIROUT)/weisskopf.o $(LIBDIROUT)/isotope_info.o $(LIBDIROUT)/cascadeProd.o $(LIBDIROUT)/edepmath.o $(LIBDIROUT)/rootUtil.o `root-config --cflags --glibs` -o $(LIBDIROUT)/libncap.so
$(BUILDDIR)/realizeCascades: $(LIBDIROUT)/libncap.so $(BUILDDIR)/realizeCascades.cpp
$(CXX) -std=c++98 -fPIC -Wl,-rpath=$(LIBDIROUT) $(CFLAGS) $(INCFLAG) $(LIBFLAG) $(BUILDDIR)/realizeCascades.cpp `root-config --cflags --glibs` -lncap -o $(BUILDDIR)/realizeCascades
clean:
rm -f $(LIBDIROUT)/*.o
rm -f $(LIBDIROUT)/*.so
rm -f $(BUILDDIR)/realizeCascades
rm -f *.o
rm -f *.so
rm -rf $(LIBDIROUT)
despite using the -std=c++11 or -std=c++98 flags once the makefile begins to compile lindhard.c as thus:
clang++ -std=c++98 -fPIC -c -D__GIT_VERSION=\"v1.0.6-73-g01bc\"
-IMersenne -Iinc src//lindhard.c `root-config --cflags --glibs` -L. -L/Users/villaa/nrCascadeSim/bin/lib
An error is thrown for each of the many times the register keyword is used:
Mersenne/MersenneTwister.hh:187:2: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
register uint32 s1;
^~~~~~~~~
I am struggling to find out the reason for this. Is the -std flag not being applied to the pre-processing of include files? Am I going about this the wrong way?
#MadScientist and #idz were correct above. The key was that the root libraries when using root-config --cflags --glibs added the following:
-stdlib=libc++ -pthread -std=c++17 -m64 -I/usr/local/Cellar/root/6.24.04/include/root -L/usr/local/Cellar/root/6.24.04/lib/root -lGui -lCore -lImt -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lROOTVecOps -lTree -lTreePlayer -lRint -lPostscript -lMatrix -lPhysics -lMathCore -lThread -lMultiProc -lROOTDataFrame -stdlib=libc++ -lpthread -lm -ldl
This came after my flag -std=c++98 and therefore overrode it.
The solution here was to move the -std=c++98 to after the root-config line.
I suppose it was technically possible that some of the ROOT code that I was using required c++17 and then I'm not sure if this could have been resolved.
But as it turns out I was using a portion of the ROOT code base that was older and likely (though I'm still not sure) didn't have any upgrades requiring c++17.
If it did I suppose my only choice would have been to update my incompatible library, Mersenne, to be compatible with c++17
PS: I know that Mersenne Twister now is implemented in C++ standard code, but for reasons I had preferred to use my old implementation.
Related
I want to add -std=c++11 to my makefile but I do not Where to add, here is my code:
hw07: test.o functions.o
g++ test.o functions.o -o hw07
test.o: test.cpp headerfile.h
g++ -c test.cpp
functions.o: functions.cpp headerfile.h
g++ -c functions.cpp
clean:
rm *.o hw07
in the above code where should I add the stdc++11 code, please help me out about...
Instead of spelling out all of the rules and all of the commands, use variables and implicit rules to build your program:
CXXFLAGS = -std=c++11
hw07: test.o functions.o
test.o: test.cpp headerfile.h
functions.o: functions.cpp headerfile.h
clean:
rm *.o hw07
This will have make build the object files using $(CXXFLAGS) as the options to pass to the compiler. Then make will build the program hw07 using the files listed in its dependencies.
Other flags that are good to have when compiling the source files are -Wall and -Wextra. Those enable more warning messages from the compiler, that in almost all cases point out suspect things that could lead to problems.
You can just add -std=c++11 after each g++:
hw07: test.o functions.o
g++ -std=c+++11 test.o functions.o -o hw07
test.o: test.cpp headerfile.h
g++ -std=c+++11 -c test.cpp
functions.o: functions.cpp headerfile.h
g++ -std=c+++11 -c functions.cpp
clean:
rm *.o hw07
Also you can use a variable:
CPP_FLAGS='-std=c++11'
hw07: test.o functions.o
g++ ${CPP_FLAGS} test.o functions.o -o hw07
test.o: test.cpp headerfile.h
g++ ${CPP_FLAGS} -c test.cpp
functions.o: functions.cpp headerfile.h
g++ ${CPP_FLAGS} -c functions.cpp
clean:
rm *.o hw07
I want to add the shared library path to my Makefile. I have put in the export command in the makefile, it even gets called, but I still have to manually export it again.
What is the correct approach?
Makefile:
SOURCES = kwest_main.c fusefunc.c dbfuse.c logging.c dbbasic.c dbinit.c dbkey.c metadata_extract.c plugins_extraction.c import.c
LIBS = -L$(LIB) -lfuse -lsqlite3 -lkw_taglib -ltag_c -ltag -Wl,-rpath=.
INCLUDE = ../include
LIB = ../lib
EXE = kwest
CC = gcc
CCFLAGS = -g -Wall -Wextra -std=gnu99 -pedantic-errors -I$(INCLUDE)
OFLAGS = -c
ARCH = $(shell getconf LONG_BIT)
X = -D_FILE_OFFSET_BITS=$(ARCH)
OBJECTS = $(SOURCES:.c=.o)
$(EXE) : $(OBJECTS)
$(CC) -o $(EXE) $(OBJECTS) $(LIBS)
%.o: %.c
$(CC) $(OFLAGS) $(CCFLAGS) $<
fusefunc.o: fusefunc.c
$(CC) $(OFLAGS) $(CCFLAGS) $< $X
kwest_libs: kw_taglib
--->export LD_LIBRARY_PATH=$(LIB):$LD_LIBRARY_PATH
kw_taglib: plugin_taglib
plugin_taglib: plugin_taglib.o kwt_upd_meta.o
gcc -g -shared -I$(INCLUDE) -Wl,-soname,libkw_taglib.so -o $(LIB)/libkw_taglib.so -ltag -ltag_c plugin_taglib.o kwt_upd_meta.o
plugin_taglib.o:
gcc -c -g -I$(INCLUDE) -Wall -Wextra -pedantic-errors -std=gnu99 -fPIC -ltag_c -c plugin_taglib.c
kwt_upd_meta.o:
g++ -c -g -I$(INCLUDE) -Wall -Wextra -pedantic-errors -fPIC -ltag kwt_upd_meta.cpp
c: clean
clean:
rm -rf *.o
rm -rf *.db
ca: cleanall
cleanall: clean
rm -rf $(EXE)
ob: cleanall
rm -rf ~/.config/$(EXE)/
Execution:
$ ./kwest mnt
./kwest: error while loading shared libraries: libkw_taglib.so: cannot open shared object file: No such file or directory
$ export LD_LIBRARY_PATH=../lib:D_LIBRARY_PATH
$ ./kwest mnt
"executes correctly"
The usual way is to copy the dynamic library during the default make and to one of the standard library path
/usr/local/bin
or one of your project library path and add the library to executable using
-L/project/specific/path
during make install.
As already mentioned here, the thing you probably want is the linker option -rpath.
Like that, you can set a default search path for the binary. Looks like you even already use -rpath in your makefile, but you specify the wrong path:
LIBS = -L$(LIB) -lfuse -lsqlite3 -lkw_taglib -ltag_c -ltag -Wl,-rpath=.
So the binary will search in the current directory for dyn-libraries.
However, you add ../lib to your LD_LIBRARY_PATH later, for execution of the binary, so the given path . seems to be wrong.
Please take a try for the following fix:
LIBS = -L$(LIB) -lfuse -lsqlite3 -lkw_taglib -ltag_c -ltag -Wl,-rpath=../lib
Like that you should not need to specify a LD_LIBRARY_PATH for execution.
I have a simple Makefile,
.PHONY: clean
PROGRAMS=$(patsubst main%.cpp,example%,$(wildcard main*.cpp))
all: ${PROGRAMS}
GCCVERSION=$(shell gcc -dumpversion)
GLCFLAGS=$(shell pkg-config --cflags gl)
CPPFLAGS=-Wall -O2 ${GLCFLAGS}
ifeq "${GCCVERSION}" "4.5.2"
CXXFLAGS=-std=c++0x
else
CXXFLAGS=-std=c++11
endif
GLLIBS=$(shell pkg-config --libs gl)
LIBS=${GLLIBS} -lglut
example%: main%.o shaders.o fileutils.o
${CXX} $^ ${LIBS} -o $#
clean:
rm -f *.o ${PROGRAMS}
But when I executed it, it delete the *.o files as last command. I don't know why:
$ make
g++ -std=c++11 -Wall -O2 -I/usr/include/libdrm -c -o main01.o main01.cpp
g++ -std=c++11 -Wall -O2 -I/usr/include/libdrm -c -o shaders.o shaders.cpp
g++ -std=c++11 -Wall -O2 -I/usr/include/libdrm -c -o fileutils.o fileutils.cpp
g++ main01.o shaders.o fileutils.o -lGL -lglut -o example01
rm main01.o fileutils.o shaders.o
Is there anything wrong with my Makefile?
Intermediate files are deleted by design: see Chained Rules in GNU make manual.
Use .SECONDARY or .PRECIOUS targets to keep your precioussss temp files.
Just to clarify the previous response, you need to add a special rule like
.PRECIOUS: myfile.o
I have several files needed to be compiled.
here is the command. the sample_client.c dependent on the lsp.o. Now I changed the lsp.c and lsp.h. How can I compile to get this change effective to lsp.o?
the main function is in the sample_client.c, lsp.c does not have a main function.
gcc -g -I/usr/include -g sample_client.c lsp.o lspmessage.pb-c.o -o sample_client -L/usr/lib -lprotobuf-c
Here is my makefile,
CC = gcc
TARGET = sample_client sample_server
CFLAGS += -g -I/usr/include
LDFLAGS += -g -lprotobuf-c -L/usr/lib
all: $(TARGET)
$(TARGET): lsp.o lspmessage.pb-c.o
%.o: %.c
$(CC) -c $(CFLAGS) $< -o $#
clean:
rm -f *.o
rm -f $(TARGET)
However, the lprotobuf-c can not be correctly linked.
run make -f Makefile
I can get the following,
lspmessage.pb-c.o: In function `lspmessage__get_packed_size':
...: undefined reference to `protobuf_c_message_get_packed_size'
lspmessage.pb-c.o: In function `lspmessage__pack':
...: undefined reference to `protobuf_c_message_pack'
I know that I can run this command,
gcc -g -I/usr/include -g sample_client.c lsp.o lspmessage.pb-c.o -o sample_client -L/usr/lib -lprotobuf-c
But what if I change the lsp.c and lsp.h ?
It looks to me like your LDFLAGS isn't correct. Try the following:
LDFLAGS += -L/usr/lib -lprotobuf-c
It looks like you had the directory -L and the library out of order.
Also, I removed the additional call to -g for you.
I am relatively new to hand crafted make files. I have put together a basic make file for building a library. I want to keep all the temporary .o files in a build directory and have the built executable stored in a bin directory.
My directory structure looks like this:
root
src/
include/
build/
bin/
Makefile
and this is what my make file looks like:
SHLIB = pg_extlib
SRC = src/file1.c \
src/file2.c
OBJS = build/file1.o \
build/file2.o
debug_build:
gcc -g -fPIC -c $(SRC) -I`pg_config --includedir` -I`pg_config --includedir-server` -I/some/required/path/include -Iinclude
gcc -shared -o bin/$(SHLIB).so $(OBJS) -lm -lpq -lmylib_core
clean:
rm -f $(SHLIB) $(OBJS)
The .o files are placed correctly in the build folder, but they also appear in the root folder (where the Makefile resides). How do I fix this?
I see how you're getting object (.o) files in the root folder, but I have no idea how you're getting them in the build folder.
Let's take this in stages. First we'll give the object files their own rules:
# Note the use of "-o ..."
build/file1.o:
gcc -g -fPIC -c src/file1.c -I`pg_config --includedir` -I`pg_config --includedir-server` -I/some/required/path/include -Iinclude -o build/file1.o
build/file2.o:
gcc -g -fPIC -c src/file2.c -I`pg_config --includedir` -I`pg_config --includedir-server` -I/some/required/path/include -Iinclude -o build/file2.o
debug_build: $(OBJS)
gcc -shared -o bin/$(SHLIB).so $(OBJS) -lm -lpq -lmylib_core
This is effective, but crude. The object files now go into build/, but there's lots of redundancy, no dependency handling. So we put in prerequisites, and assuming you're using GNUMake (which you should), we can use Automatic Variables (and I'll abbreviate the -I string just for readability):
build/file1.o: src/file1.c
gcc -g -fPIC -c $< -I... -o $#
build/file2.o: src/file2.c
gcc -g -fPIC -c $< -I... -o $#
debug_build: $(OBJS)
gcc -shared -o bin/$(SHLIB).so $^ -lm -lpq -lmylib_core
Notice that the commands in the object rules are now exactly the same. So we can combine those two rules a couple of different ways. The simplest is:
build/file1.o: src/file1.c
build/file2.o: src/file2.c
build/file1.o build/file2.o:
gcc -g -fPIC -c $< -I... -o $#
Now one or two more little tweaks and we're good to go:
build/file1.o: src/file1.c
build/file2.o: src/file2.c
build/file1.o build/file2.o:
gcc -g -fPIC -c $< -I`pg_config --includedir` -I`pg_config --includedir-server` -I/some/required/path/include -Iinclude -o $#
debug_build: $(OBJS)
gcc -shared -o bin/$(SHLIB).so $^ -lm -lpq -lmylib_core
There are more sophisticated tricks, but that should be plenty for now.