I've been messing around with some source files (coreutils package source for example), adding to them asynchronous I/O functionality. Now I want to compile, but I need to add -lrt flag to gcc.
What I did is shoving it somewhere to the Makefile file. It once took me an hour to find where to put it so it will work.
I wonder, is there a way to add it during the ./configure phase, so the Makefile will be created automatically and things will just compile with the -lrt flag?
I've tried configuring the additional flag with:
./configure CFLAGS='-g -O2 -lrt'
and indeed I see a change in the Makefile, but it still doesn't work.
Using
make V=1
I see that make executes:
gcc -std=gnu99 -g -O2 -lrt -Wl,--as-needed -o src/wc src/wc.o src/libver.a lib/libcoreutils.a lib/libcoreutils.a
notice that -lrt is somewhere in the middle, so for some reason it doesn't work. But if this get executed:
gcc -std=gnu99 -g -O2 -Wl,--as-needed -o src/wc src/wc.o src/libver.a lib/libcoreutils.a lib/libcoreutils.a -lrt
it works. Notice that -lrt is at the end.
How can I append a flag to the end automatically through ./configure? or is there some other way to do that?
Partial Solution:
After running ./configure, I've edited the Makefile and added -lrt to the LDADD variable - that done the trick.
Related
I can’t figure out how to give my R package’s shared library’s debug symbols source line information. What am I missing?
I create the following src/Makevars file:
PKG_CXXFLAGS=-O0 -ggdb
PKG_LIBS=-O0 -ggdb
I compile the package using R CMD INSTALL --no-multiarch --with-keep.source:
* installing to library ‘~/.local/lib/R/3.6’
* installing *source* package ‘reticulate’ ...
** using staged installation
g++ -std=gnu++11 -I"/usr/include/R/" -DNDEBUG -I"$HOME/.local/lib/R/3.6/Rcpp/include" -D_FORTIFY_SOURCE=2 -O0 -ggdb -fpic -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -c RcppExports.cpp -o RcppExports.o
** libs
g++ -std=gnu++11 -shared -L/usr/lib64/R/lib -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -o reticulate.so RcppExports.o event_loop.o libpython.o output.o python.o readline.o -O0 -ggdb -L/usr/lib64/R/lib -lR
installing to ~/.local/lib/R/3.6/00LOCK-reticulate/00new/reticulate/libs
I debug like this:
R -d gdb --slave -e 'reticulate::py_eval("print")()'
GNU gdb (GDB) 8.3
[...]
(No debugging symbols found in /usr/lib64/R/bin/exec/R)
(gdb) break py_get_formals
Function "py_get_formals" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (py_get_formals) pending.
(gdb) run
Starting program: /usr/lib/R/bin/exec/R --slave -e reticulate::py_eval\(\"print\"\)\(\)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[...]
Thread 1 "R" hit Breakpoint 1, 0x00007fffeb6b79a0 in py_get_formals(PyObjectRef, bool) () from /home/angerer/.local/lib/R/3.6/reticulate/libs/reticulate.so
(gdb) step
Single stepping until exit from function _Z14py_get_formals11PyObjectRefb,
which has no line number information.
[...]
Why does my function not have line numbers even though I specified -ggdb in both compilation? I see that only RcppExports.cpp is mentioned in the command line, is that the problem? If so, how can I change this?
Changing the Makevars doesn’t prompt recompilation.
I needed to rm -f src/*.o src/*.so before the object files get recompiled.
This is specifically for Windows. The simplest way to do it is to set the R_MAKEVARS_USER environment to point to the Makevars.win file. That seems to work. However, debug break points have stopped working!!!!
I can’t figure out how to give my R package’s shared library’s debug symbols source line information. What am I missing?
I create the following src/Makevars file:
PKG_CXXFLAGS=-O0 -ggdb
PKG_LIBS=-O0 -ggdb
I compile the package using R CMD INSTALL --no-multiarch --with-keep.source:
* installing to library ‘~/.local/lib/R/3.6’
* installing *source* package ‘reticulate’ ...
** using staged installation
g++ -std=gnu++11 -I"/usr/include/R/" -DNDEBUG -I"$HOME/.local/lib/R/3.6/Rcpp/include" -D_FORTIFY_SOURCE=2 -O0 -ggdb -fpic -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -c RcppExports.cpp -o RcppExports.o
** libs
g++ -std=gnu++11 -shared -L/usr/lib64/R/lib -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -o reticulate.so RcppExports.o event_loop.o libpython.o output.o python.o readline.o -O0 -ggdb -L/usr/lib64/R/lib -lR
installing to ~/.local/lib/R/3.6/00LOCK-reticulate/00new/reticulate/libs
I debug like this:
R -d gdb --slave -e 'reticulate::py_eval("print")()'
GNU gdb (GDB) 8.3
[...]
(No debugging symbols found in /usr/lib64/R/bin/exec/R)
(gdb) break py_get_formals
Function "py_get_formals" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (py_get_formals) pending.
(gdb) run
Starting program: /usr/lib/R/bin/exec/R --slave -e reticulate::py_eval\(\"print\"\)\(\)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[...]
Thread 1 "R" hit Breakpoint 1, 0x00007fffeb6b79a0 in py_get_formals(PyObjectRef, bool) () from /home/angerer/.local/lib/R/3.6/reticulate/libs/reticulate.so
(gdb) step
Single stepping until exit from function _Z14py_get_formals11PyObjectRefb,
which has no line number information.
[...]
Why does my function not have line numbers even though I specified -ggdb in both compilation? I see that only RcppExports.cpp is mentioned in the command line, is that the problem? If so, how can I change this?
Changing the Makevars doesn’t prompt recompilation.
I needed to rm -f src/*.o src/*.so before the object files get recompiled.
This is specifically for Windows. The simplest way to do it is to set the R_MAKEVARS_USER environment to point to the Makevars.win file. That seems to work. However, debug break points have stopped working!!!!
I am trying to set up Travis-CI to build this R package. The package builds locally with the following steps that closely mirror the build process on Travis (failed build here):
git clone --depth=50 --branch=master https://github.com/weinstockj/htslibr.git weinstockj/htslibr
cd weinstockj/htslibr/
git submodule update --init --recursive
cd htslibr/
R -e 'install.packages("Rcpp")'
R CMD build .
Travis fails with an error that suggests it cannot find a header file that is in a sub-directory of htslibr/src. Why does R CMD build fail to find the header on Travis (again, no issue locally)?
Travis set up is here , and locally I am also using Ubuntu 16.04.
Here an extract from the failed build log:
mkdir -p /tmp/Rtmpy1bhv4/Rinst23036acf1e4/htslibr/inst/include
cp htslib/htslib/*.h /tmp/Rtmpy1bhv4/Rinst23036acf1e4/htslibr/inst/include
g++ -std=gnu++11 -I"/home/travis/R-bin/lib/R/include" -DNDEBUG -I"/usr/local/lib/R/site-library/Rcpp/include" -I/home/travis/R-bin/include -fpic -g -O2 -c RcppExports.cpp -o RcppExports.o
g++ -std=gnu++11 -I"/home/travis/R-bin/lib/R/include" -DNDEBUG -I"/usr/local/lib/R/site-library/Rcpp/include" -I/home/travis/R-bin/include -fpic -g -O2 -c util.cpp -o util.o
util.cpp:2:24: fatal error: htslib/hts.h: No such file or directory
We see that while the headers are copied to /tmp/Rtmpy1bhv4/Rinst23036acf1e4/htslibr/inst/include, this directory is not on the include path. You can fix this by adding
PKG_CPPFLAGS = -I../inst/include -DSTRICT_R_HEADERS
to Makevars (STRICT_R_HEADERS is not needed but "best practice") and using #include <hts.h> in util.cpp. However, I am not convinced that it is correct to copy the header files to inst/include in the first place. After all, these header files do not represent an API that your packge is providing to other packages. Instead, it is the API of a library that you package uses internally. I would therefore suggest to not copy the header files and use
PKG_CPPFLAGS = -Ihtslib -DSTRICT_R_HEADERS
in Makevars.
BTW, Writing R Extensions advocates a different usage pattern for the targets:
all: $(SHLIB)
$(SHLIB): <any other needed targets>
Though this point is irrelevant if you follow my suggestion to not copy the headers.
Error i get!-----------------/
This is what my makefile looks like/
i am trying to Compile cookie.cpp to produce cookie.o.
Compile mainProg.cpp to produce mainProg.o.
Link the the .o files to produce an executable program named playChomp
mainprog.cpp' file has the header of cookie.h
i am working in unix in an ssh terminal linux server
makefile..
**all: playChomp
playChomp: mainProg.o cookie.o cookie.h
g++ -g -DDEBUG mainProg.o cookie.o -o playChomp
cookie.o:cookie.cpp
g++ -g -DDEBUG -c cookie.cpp
mainProg.o: mainProg.cpp cookie.h
g++ -g -DDEBUG -c mainProg.cpp**
You need to post some basic information that helps the people to understand better your problem. A few suggestions:
Try making a more meaningful title, put the error message that you receive into the title.
Put the source code of your program into your post. If possible, try to reduce it to a minimum content that still generates the same error message.
Inform your Operational System, Language that you are working on, what version, etc.
Given the following directory listing:
$ ls
cookie.cpp cookie.h mainProg.cpp Makefile
Then the Makefile you have provided:
all: playChomp
playChomp: mainProg.o cookie.o cookie.h
g++ -g -DDEBUG mainProg.o cookie.o -o playChomp
cookie.o: cookie.cpp
g++ -g -DDEBUG -c cookie.cpp
mainProg.o: mainProg.cpp cookie.h
g++ -g -DDEBUG -c mainProg.cpp
Will produce the desired executable:
$ make all
g++ -g -DDEBUG -c mainProg.cpp
g++ -g -DDEBUG -c cookie.cpp
g++ -g -DDEBUG mainProg.o cookie.o -o playChomp
$ ./playChomp
Hello World!
The error you are getting suggests the file is not there (in the directory where you are executing make). Ensure that you are calling make from the directory where those files exist, and triple check the spelling (i.e. make sure you have cookie.h, not Cookie.h, etc.)
I built a Qt project in Debug mode with Qt Creator, ran Callgrind to generate profiling data and tried loading it into Cachegrind. I noticed that I only see profiling information for Qt classes, so I figured I must have forgotten to turn on a crucial flag.
Qt Creator's qmake command looks like this:
qmake /path/to/project/MyProject/MyProject.pro -r -spec linux-g++-64 CONFIG+=debug
Sample compile output for one file:
g++ -c -m64 -pipe -g -Wall -W -D_REENTRANT -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++-64 -I../Flowchart -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include -I. -I. -I../Flowchart -I. -o main.o ../Flowchart/main.cpp
The -g flag is there, so debug information should be available. I verified this by running gdb on the executable and trying to look at some random source code with l.
The Callgrind command I used was:
valgrind --tool=callgrind ./MyProject
What am I missing here?
You should do:
valgrind --tool=callgrind --trace-children=yes --demangle=yes ./MyProject
Also depending on the distribution of Linux you may have to make sure that you have the Debug information in the QT libraries you are linking against.