I have a strange link error with SQLite. I have the following code:
void TestSQLiteTemp()
{
/* sqlite3_initialize(); */
sqlite3_close( db );
}
I can compile and link and everything is fine:
perdue#minervatest04> ldd bin/tests
libCAENVME.so => /usr/lib/libCAENVME.so (0x00002afaffc42000)
...
libsqlite3.so.0 => /home/perdue/software/minervadaq/minervadaq/sqlite/lib/libsqlite3.so.0 (0x00002afafff8f000)
...
But, if I uncomment the sqlite3_initialize line, ld fails:
g++ -o tests TestSuite.o -L/home/perdue/software/minervadaq/minervadaq/lib -lhardware -lminerva_workers -L/usr/lib64 -ldl -L/work/software/CAENVMElib/lib/x86_64 -lCAENVME -L/usr/local/lib -llog4cpp -L/usr/lib64 -lpthread -L/usr/lib64 -L/home/perdue/software/minervadaq/minervadaq/sqlite/lib/ -lsqlite3
TestSuite.o: In function TestSQLiteTemp():
/home/perdue/software/minervadaq/minervadaq/tests/TestSuite.cpp:199: undefined reference to `sqlite3_initialize'
Does anyone know why some functions might be okay, but others fail to link?
To answer my own question, the problem was that there was an older version of sqlite in /usr/lib64 and I had that appearing in my linker list before the custom install area. If I move my custom lib area to the front of the list of library paths, everything works.
Related
I am using Rcpp to speed up a function that gets called repeatedly in R (3.4, Windows7) and I was hoping to change the compiler settings.
When I call:
sourceCpp("scoreseq1.1.cc", verbose=TRUE)
Part of the output reads:
C:/RBuildTools/3.4/mingw_64/bin/g++ -I"C:/PROGRA~1/R/R-34~1.1/include" -O2 -Wall -mtune=core2 -c scoreseq1.1.cc -o scoreseq1.1.o
I would like to change -mtune to haswell, and -O2 to -O3 in search of some performance improvements.
Is there a way to do that through the sourceCpp or cppFunction, do I need a special header in my.cc file, or do I need to I need to modify some file on my system (and if so, what file?!)
Thanks!
No, you can't (easily), and in general not from a function.
These settings are "fixed" from when R itself is built. You can edit the file -- but you will have to so each time R is rebuilt / reinstalled.
On my box the file is $(R RHOME)/etc/Makeconf.
Just in case someone has a similar problem. You can do this in your C++ source. The following overrides command-line compiler settings:
void
__attribute__((optimize("-O3"),target("tune=haswell")))
foo()
{
// your code goes here
}
For reference take a look at: https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html.
When I try to install.packages('readr'), I get errors deriving from
clang++ -I/usr/local/lib/R/include -DNDEBUG -I/usr/local/lib/R/include
-I/usr/local/include -I"/usr/local/lib/R/site-library/Rcpp/include"
-I"/usr/local/lib/R/site-library/BH/include"
-fpic -g -O2 -O3 -fstack-protector --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security
-D_FORTIFY_SOURCE=2 -g -std=c++11
-c Collector.cpp -o Collector.o
I'm checking ~/.R/Makevars and /etc/R/Makeconf for where this clang++ -I.... command might be set but neither contains that language.
echo $CXX
echo $CC
are both empty, and setting them to something else before starting R hasn't helped. Starting R --no-environ doesn't change the error message either.
So where might these environment variables be set, how can I change or disable them, and how do I figure out for next time where this "global variable from somewhere" error is coming from?
Thanks in advance.
I may have neededto addexport LIBRARY_PATH=/opt/boost_1_61_0/boost/to my~/.bashrc`.
This doesn't answer my question (of how to clean the clang call), but changing the CXX value in ~/.R/Makevars from clang++ to g++ did fix my immediate problem of not being able to install readr.
Here are the build errors under clang:
In file included from Collector.cpp:4:
In file included from ./Collector.h:8:
In file included from ./Token.h:6:
In file included from ./Source.h:5:
In file included from ./boost.h:13:
In file included from /usr/local/lib/R/site-library/BH/include/boost/spirit/include/qi.hpp:16:
In file included from /usr/local/lib/R/site-library/BH/include/boost/spirit/home/qi.hpp:14:
In file included from /usr/local/lib/R/site-library/BH/include/boost/spirit/home/qi/action.hpp:14:
In file included from /usr/local/lib/R/site-library/BH/include/boost/spirit/home/qi/action/action.hpp:14:
In file included from /usr/local/lib/R/site-library/BH/include/boost/spirit/home/qi/meta_compiler.hpp:14:
In file included from /usr/local/lib/R/site-library/BH/include/boost/spirit/home/support/meta_compiler.hpp:19:
In file included from /usr/local/lib/R/site-library/BH/include/boost/proto/proto.hpp:12:
In file included from /usr/local/lib/R/site-library/BH/include/boost/proto/core.hpp:21:
In file included from /usr/local/lib/R/site-library/BH/include/boost/proto/fusion.hpp:22:
In file included from /usr/local/lib/R/site-library/BH/include/boost/fusion/include/intrinsic.hpp:11:
In file included from /usr/local/lib/R/site-library/BH/include/boost/fusion/sequence/intrinsic.hpp:23:
In file included from /usr/local/lib/R/site-library/BH/include/boost/fusion/sequence/intrinsic/swap.hpp:15:
In file included from /usr/local/lib/R/site-library/BH/include/boost/fusion/view/zip_view.hpp:12:
In file included from /usr/local/lib/R/site-library/BH/include/boost/fusion/view/zip_view/zip_view.hpp:16:
In file included from /usr/local/lib/R/site-library/BH/include/boost/fusion/view/zip_view/detail/begin_impl.hpp:14:
In file included from /usr/local/lib/R/site-library/BH/include/boost/fusion/algorithm/transformation/transform.hpp:11:
In file included from /usr/local/lib/R/site-library/BH/include/boost/fusion/view/transform_view/transform_view.hpp:22:
In file included from /usr/local/lib/R/site-library/BH/include/boost/fusion/container/vector/vector10.hpp:25:
/usr/local/lib/R/site-library/BH/include/boost/fusion/container/vector/vector.hpp:261:61: error:
invalid use of 'this' outside of a nonstatic member function
auto at_impl(J) -> decltype(at_detail<J::value>(this))
^
/usr/local/lib/R/site-library/BH/include/boost/fusion/container/vector/vector.hpp:262:13: error:
type name requires a specifier or qualifier
{
^
/usr/local/lib/R/site-library/BH/include/boost/fusion/container/vector/vector.hpp:262:13: error:
C++ requires a type specifier for all declarations
{
^
/usr/local/lib/R/site-library/BH/include/boost/fusion/container/vector/vector.hpp:261:13: error:
'auto' return without trailing return type
auto at_impl(J) -> decltype(at_detail<J::value>(this))
^
/usr/local/lib/R/site-library/BH/include/boost/fusion/container/vector/vector.hpp:268:67: error:
invalid use of 'this' outside of a nonstatic member function
auto at_impl(J) const -> decltype(at_detail<J::value>(this))
^
/usr/local/lib/R/site-library/BH/include/boost/fusion/container/vector/vector.hpp:269:13: error:
type name requires a specifier or qualifier
{
^
/usr/local/lib/R/site-library/BH/include/boost/fusion/container/vector/vector.hpp:269:13: error:
C++ requires a type specifier for all declarations
{
^
/usr/local/lib/R/site-library/BH/include/boost/fusion/container/vector/vector.hpp:268:13: error:
'auto' return without trailing return type
auto at_impl(J) const -> decltype(at_detail<J::value>(this))
^
8 errors generated.
make: *** [Collector.o] Error 1
ERROR: compilation failed for package ‘readr’
If I compile with g++ instead of clang++, the errors become warnings:
In file included from /usr/local/lib/R/site-library/BH/include/boost/iostreams/detail/is_dereferenceable.hpp:12:0,
from /usr/local/lib/R/site-library/BH/include/boost/iostreams/detail/resolve.hpp:26,
from /usr/local/lib/R/site-library/BH/include/boost/iostreams/detail/push.hpp:24,
from /usr/local/lib/R/site-library/BH/include/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:31,
from /usr/local/lib/R/site-library/BH/include/boost/iostreams/stream_buffer.hpp:22,
from /usr/local/lib/R/site-library/BH/include/boost/iostreams/stream.hpp:21,
from /usr/local/lib/R/site-library/BH/include/boost/spirit/home/qi/stream/detail/iterator_source.hpp:14,
from /usr/local/lib/R/site-library/BH/include/boost/spirit/home/qi/stream/stream.hpp:16,
from /usr/local/lib/R/site-library/BH/include/boost/spirit/home/qi/stream.hpp:15,
from /usr/local/lib/R/site-library/BH/include/boost/spirit/home/qi.hpp:30,
from /usr/local/lib/R/site-library/BH/include/boost/spirit/include/qi.hpp:16,
from boost.h:14,
from Source.h:5,
from Token.h:6,
from Collector.h:8,
from Collector.cpp:4:
/usr/local/lib/R/site-library/BH/include/boost/type_traits/detail/bool_trait_def.hpp:18:79: note: #pragma message: NOTE: Use of this header (bool_trait_def.hpp) is deprecated
# pragma message("NOTE: Use of this header (bool_trait_def.hpp) is deprecated")
^
In file included from /usr/local/lib/R/site-library/BH/include/boost/type_traits/detail/bool_trait_def.hpp:21:0,
from /usr/local/lib/R/site-library/BH/include/boost/iostreams/detail/is_dereferenceable.hpp:12,
from /usr/local/lib/R/site-library/BH/include/boost/iostreams/detail/resolve.hpp:26,
from /usr/local/lib/R/site-library/BH/include/boost/iostreams/detail/push.hpp:24,
from /usr/local/lib/R/site-library/BH/include/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:31,
from /usr/local/lib/R/site-library/BH/include/boost/iostreams/stream_buffer.hpp:22,
from /usr/local/lib/R/site-library/BH/include/boost/iostreams/stream.hpp:21,
from /usr/local/lib/R/site-library/BH/include/boost/spirit/home/qi/stream/detail/iterator_source.hpp:14,
from /usr/local/lib/R/site-library/BH/include/boost/spirit/home/qi/stream/stream.hpp:16,
from /usr/local/lib/R/site-library/BH/include/boost/spirit/home/qi/stream.hpp:15,
from /usr/local/lib/R/site-library/BH/include/boost/spirit/home/qi.hpp:30,
from /usr/local/lib/R/site-library/BH/include/boost/spirit/include/qi.hpp:16,
from boost.h:14,
from Source.h:5,
from Token.h:6,
from Collector.h:8,
from Collector.cpp:4:
/usr/local/lib/R/site-library/BH/include/boost/type_traits/detail/template_arity_spec.hpp:13:84: note: #pragma message: NOTE: Use of this header (template_arity_spec.hpp) is deprecated
gma message("NOTE: Use of this header (template_arity_spec.hpp) is deprecated")
^
In file included from /usr/local/lib/R/site-library/BH/include/boost/iostreams/detail/is_dereferenceable.hpp:13:0,
from /usr/local/lib/R/site-library/BH/include/boost/iostreams/detail/resolve.hpp:26,
from /usr/local/lib/R/site-library/BH/include/boost/iostreams/detail/push.hpp:24,
from /usr/local/lib/R/site-library/BH/include/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:31,
from /usr/local/lib/R/site-library/BH/include/boost/iostreams/stream_buffer.hpp:22,
from /usr/local/lib/R/site-library/BH/include/boost/iostreams/stream.hpp:21,
from /usr/local/lib/R/site-library/BH/include/boost/spirit/home/qi/stream/detail/iterator_source.hpp:14,
from /usr/local/lib/R/site-library/BH/include/boost/spirit/home/qi/stream/stream.hpp:16,
from /usr/local/lib/R/site-library/BH/include/boost/spirit/home/qi/stream.hpp:15,
from /usr/local/lib/R/site-library/BH/include/boost/spirit/home/qi.hpp:30,
from /usr/local/lib/R/site-library/BH/include/boost/spirit/include/qi.hpp:16,
from boost.h:14,
from Source.h:5,
from Token.h:6,
from Collector.h:8,
from Collector.cpp:4:
(error is too long, pasted at http://ix.io/11F0)
So spirit and fusion are disliked by both compilers (with my chosen flags, which I still can't figure out how to clean).
I am getting the following syntax error:
../stat-time.h:58:[kernel] user error: Cannot find field st_atim
This is in the gnu stat-time.h by Paul Eggert. Here's the snippet causing the error:
#define STAT_TIMESPEC(st, st_xtim) ((st)->st_xtim)
long int get_stat_atime_ns(struct stat const *st) {
...
// 58:
return STAT_TIMESPEC(st, st_atim).tv_nsec;
...
}
I tried to preprocess the file first, then run frama-c on the preprocessed file, but that didn't help. Frama-c still reported the same error at the same location, even though the file was preprocessed correctly and the macro was correctly expanded! I invoked gcc as follows, for preprocessing:
gcc -E -C -I. -dD -nostdinc -D__FC_MACHDEP_X86_32 -I/usr/local/share/frama-c/libc
Any ideas?
I figured out the solution. Apparently, the frama-c headers in /usr/local/share/frama-c/libc/__fc_define_stat.h lacked the nsec granularity fields in struct stat. I added the following fields to struct stat to fix the problem:
unsigned long int st_atimensec;
unsigned long int st_mtimensec;
unsigned long int st_ctimensec;
Also, make sure to use the frama-c headers while configuring, e.g., configure CPP='gcc -E -C -dD -nostdinc -I/usr/local/share/frama-c/libc. If not, you will need to undefine the following two macros:
HAVE_STRUCT_STAT_ST_ATIM_TV_NSEC, HAVE_STRUCT_STAT_ST_ATIMESPEC_TV_NSEC, and define the following macro: HAVE_STRUCT_STAT_ST_ATIMENSEC in a header file, and include it in config.h or in __fc_define_stat.h
I am trying to add some compilation options in Automake, but none of the approaches work.
Here is my configure.ac:
AC_INIT(...)
AC_PREREQ([2.59])
AC_CONFIG_AUX_DIR([build-aux])
AM_INIT_AUTOMAKE([1.10 foreign -Wall no-define])
AC_PROG_CXX
AC_PROG_LIBTOOL
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([Makefile src/Makefile test/Makefile])
AC_LANG(C++)
AC_OUTPUT
And I have the parent Makefile.am (in top-level dir):
#AM_CFLAGS = ... # doesn't work
AUTOMAKE_OPTIONS = subdir-objects
ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS}
SUBDIRS = src test
dist_noinst_SCRIPTS = autogen.sh
and a Makefile.am for each source dir; src/Makefile:
include_HEADERS = ...
lib_LIBRARIES = ...
and test/Makefile:
#AM_CFLAGS = ... # doesn't work
bin_PROGRAMS = myprog #test
myprog_SOURCES = ...
myprog_LDADD = ../src/libmylib.a
#myprog_CFLAGS = ... # Doesn't work either
I tried uncommenting all combinations of commented lines, i.e.:
add AM_CFLAGS = ... to the parent Makefile.am - this should set the CFLAGS for all affected sources
add AM_CFLAGS = ... to other two Makefile.ams
add myprog_CFLAGS = ... to Makefile.am (this should set CFLAGS when compiling myprog)
but none of these has any effects. Both my program (myprog) and its library (mylib) are kept being compiled / linked with some default flags which are something like -DHAVE_CONFIG -g -O2.
I also tried using INCLUDES instead of AM_CFLAGS, but didn't help.
Anybody has some idea what is going on here and how to fix it?
It looks like you're compiling C++, in which case the variable to use is AM_CXXFLAGS.
Setting AM_CXXFLAGS should be in the Makefile.am that declares things you're actually compiling (i.e., bin_PROGRAMS, lib_LTLIBRARIES, ...).
If you're repeating yourself, don't forget automake supports an include statement.
Recursive make considered harmful. Modern automake supports subdir-objects. If one Makefile.am gets out of hand, use include statements.
The modern way to turn on libtool is LT_INIT, not AC_PROG_LIBTOOL.
AC_LANG(C++) doesn't do anything at point of configure.ac. It sets the language to use when running configure tests. Besides, AC_LANG_PUSH and AC_LANG_POP are smarter ways of doing that.
Why are you assigning to ACLOCAL_AMFLAGS like that?
I tried adding AM_CFLAGS to the parent Makefile.am as suggested, which didn't work. When I added it to the relevant Makefile.am, it ended introducing two conflicting -g options as shown below:
libtool: link: gcc -std=gnu99 -g -O0 -g -O2 -Wl -pthread ...
The correct way to disable optimization is to add CFLAGS = -g -O0 to the Makefile.am where it's needed. Try deleting Makefile.in and Makefile (no extension) if the change doesn't take effect for some reason.
Here's the correct linker directive:
libtool: link: gcc -std=gnu99 -g -O0 -Wl -pthread ...
How do I set the LD_LIBRARY_PATH env variable from a Makefile?
I have some source code that links to a shared library that in turn links to a different shared library (more than 1). The Makefile for building the application only knows about the first shared library.
If I want to build this, I have to specify:
#export LD_LIBRARY_PATH=/path/to/the/shared/libs (for bash)
and that works fine.
However, I would like to do this from the Makefile itself.
Yes, "export" is the correct directive to use. It is documented in detail here. This is the same mechanism as make itself uses to propagate variables to sub-makes. The drawback is that you cannot selectively pass down the variable to some commands and not to others.
There are two other options I can think of:
Using .EXPORT_ALL_VARIABLES (specify as a target somewhere), causes all variables to be exported to the environment of sub-commands.
Specify on the command line:
foo:
EXPORTEDVAR=somevalue gcc $< -o $#
If you don't want to export the LD_LIBRARY_PATH variable within the makefile (e.g. because you have recursive Makefiles which all add to the variable), you can keep it bound to all calls to your compiler and linker.
Either you add it directly to all gcc and ld calls within your target rules, e.g.
my_target: my_target.o
LD_LIBRARY_PATH=/my/library/path gcc -o my_target my_target.o
or you set the global make variables that define the compilers include the path, e.g.:
CC=LD_LIBRARY_PATH=/my/library/path gcc
CPP=LD_LIBRARY_PATH=/my/library/path gcc
CXX=LD_LIBRARY_PATH=/my/library/path gcc
I chose gcc as compiler but of course you can use any compiler you like.
I had the same problem, I had to export LD_LIBRARY_PATH as you did:
export LD_LIBRARY_PATH=/path/to/the/shared/libs ; my_command
My friend showed me an alternative when LD_LIBRARY_PATH only applies to one command, notice no semicolon below.
LD_LIBRARY_PATH=/path/to/the/shared/libs my_command
This article explains more.
I had tried adding:
export LD_LIBRARY_PATH=/path/to/the/shared/libs
which apparently works fine.
I was getting errors because my /path/to/the/shared/libs was incorrect.
Would still be good to know what others do for this and/if there is a better way.
If you want to set LD_LIBRARY_PATH for a particular make , try this LD_LIBRARY_PATH=/path/to/the/shared/libs make.
Adding this to the top of the Makefile worked for me:
export LD_LIBRARY_PATH := $(HOME)/lib
Pay attention not to add any extra spaces to the end of the line. I wasted some time until I realized that was the problem.