#8 closed defect (worksforme)
Missing or spurious ODBC dependency
| Reported by: | Vladimír Štill | Owned by: | mornfall |
|---|---|---|---|
| Priority: | major | Milestone: | 5.0 |
| Component: | bench | Keywords: | |
| Cc: | kdudka@… |
Description
As reported by Kamil:
ODBC is missing in the build dependencies. On Fedora 27 it is necessary to install unixODBC-devel, otherwise, the following error is produces:
[1898/5410] Building CXX object external/nanodbc/CMakeFiles/nanodbc.dir/nanodbc.cpp.o
FAILED: external/nanodbc/CMakeFiles/nanodbc.dir/nanodbc.cpp.o
/home/kdudka/divine/_build.toolchain/clang//bin/clang++ -DBRICKS_HAVE_DIRENT_D_TYPE -DBRICKS_HAVE_LLVM -DNANODBC_USE_CPP11 -DOPT_SIM=1 -DOPT_SQL=1 -DOPT_STP=1 -DOPT_TBBMALLOC=1 -DOPT_Z3=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I../llvm/include -Illvm/include -I../clang/include -Iclang/include -I../bricks -I/usr/include/valgrind -isystem /home/kdudka/divine/dios/libcxxabi/include -isystem /home/kdudka/divine/dios/libcxx/include -isystem /home/kdudka/divine/dios/libunwind/include -stdlib=libc++ -nostdinc++ -Wno-unused-command-line-argument -std=c++1z -O3 -g -DNDEBUG -DNVALGRIND -fPIC -DHAVE_UNISTD_H -DHAVE_PWD_H -DHAVE_SYS_TYPES_H -DHAVE_LONG_LONG -DSIZEOF_LONG_INT=8 -I/usr/include -fcolor-diagnostics -MD -MT external/nanodbc/CMakeFiles/nanodbc.dir/nanodbc.cpp.o -MF external/nanodbc/CMakeFiles/nanodbc.dir/nanodbc.cpp.o.d -o external/nanodbc/CMakeFiles/nanodbc.dir/nanodbc.cpp.o -c ../external/nanodbc/nanodbc.cpp
../external/nanodbc/nanodbc.cpp:56:10: fatal error: 'sql.h' file not found
#include <sql.h>
^~~~~~~
1 error generated.
I don't think ODBC is needed for anything but divbench. It seems to me that either the detection of ODBC in CMake is faulty, or we try to build ODBC regardless of this detection.
Note: See
TracTickets for help on using
tickets.
Probably a cmake glitch, or a case of stale cache (odbc headers removed after configuring? or maybe odbc-config installed but not the headers?). We do not build nanodbc unless OPT_SQL is set, and we default OPT_SQL to ${ODBC_FOUND}. Please provide steps to reproduce if this is still a problem.