I have installed this driver for long time, but failed. There is the same mistake as following:
scons: Reading SConscript files ...
Checking for C++ library boost_thread-mt... (cached) no
Checking for C++ library boost_thread... (cached) yes
Checking for C++ library boost_filesystem-mt... (cached) no
Checking for C++ library boost_filesystem... (cached) yes
Checking for C++ library boost_system-mt... (cached) no
Checking for C++ library boost_system... (cached) yes
scons: done reading SConscript files.
scons: Building targets ...
g++ -o build/mongo/client/dbclient_rs.o -c -O3 -pthread -D_SCONS -DMONGO_EXPOSE_MACROS -Ibuild -Isrc -Ibuild/mongo -Isrc/mongo src/mongo/client/dbclient_rs.cpp
In file included from /usr/local/include/boost/filesystem/path.hpp:24,
from src/mongo/util/paths.h:26,
from src/mongo/db/client.h:38,
from src/mongo/db/curop.h:23,
from src/mongo/db/curop-inl.h:1,
from src/mongo/db/instance.h:23,
from src/mongo/db/dbmessage.h:25,
from src/mongo/client/dbclient_rs.cpp:27:
/usr/local/include/boost/filesystem/config.hpp:16:5: error: #error Compiling Filesystem version 3 file with BOOST_FILESYSTEM_VERSION defined != 3
scons: *** [build/mongo/client/dbclient_rs.o] Error 1
scons: building terminated because of erro`enter code here`rs.`enter code here`
before install, I have installed the boost 1.5， pcre8.3, and I want install mongodb driver 2.2
Any ideas ? Thanks!
I encountered the same problem with you.
In mongodb C++ driver source src/mongo/pch.h
#define BOOST_FILESYSTEM_VERSION 2
but in /usr/local/include/boost/filesystem/config.hpp:
# if defined(BOOST_FILESYSTEM_VERSION) && BOOST_FILESYSTEM_VERSION != 3
# error Compiling Filesystem version 3 file with BOOST_FILESYSTEM_VERSION defined != 3
# endif
this is the problem.
And I change src/mongo/pch.h to
#define BOOST_FILESYSTEM_VERSION 3
then scons again, the compiles correctly.
Some solution from Internet :
RESOLVED: I have v2 of the 1.44 boost libraries, but had "#define BOOST_FILESYSTEM_VERSION 3" in my header (a co-worker using another version had added it). If I comment this directive, my code compiles correctly. Looks like we need to synchronize our libraries.
Related
I'm trying to build CMake 3.15.5 on a 20.04 xubuntu machine (but I also tried 18.04 and 20.10 with the same results).
The error is as follows:
loading initial cache file /home/max/Lavori/nova/src/repos/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/Bootstrap.cmk/InitialCacheFlags.cmake
-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Checking if compiler supports C11 _Thread_local
-- Checking if compiler supports C11 _Thread_local - yes
-- Checking if compiler supports needed C++17 constructs
-- Checking if compiler supports needed C++17 constructs - yes
-- Checking if compiler supports C++ make_unique
-- Checking if compiler supports C++ make_unique - no
-- Checking if compiler supports C++ unique_ptr
-- Checking if compiler supports C++ unique_ptr - no
CMake Error at CMakeLists.txt:92 (message):
The C++ compiler does not support C++11 (e.g. std::unique_ptr).
-- Configuring incomplete, errors occurred!
See also "/home/max/Lavori/nova/src/repos/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/CMakeFiles/CMakeOutput.log".
See also "/home/max/Lavori/nova/src/repos/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/CMakeFiles/CMakeError.log".
---------------------------------------------
Error when bootstrapping CMake:
Problem while running initial CMake
I am absolutely sure that g++ 9.3.0 supports C++11, so where could the problem be?
(EDIT: added CMakeError.log)
Here is the CMakeError.log file:
Determining if compiler supports C++ make_unique failed with the following output:
Change Dir: /home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/make cmTC_f5a77/fast && make[2]: Entering directory '/home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/CMakeFiles/CMakeTmp'
make[2]: Warning: File 'Makefile' has modification time 0,27 s in the future
make -f CMakeFiles/cmTC_f5a77.dir/build.make CMakeFiles/cmTC_f5a77.dir/build
make[3]: Entering directory '/home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/CMakeFiles/CMakeTmp'
make[3]: Warning: File 'CMakeFiles/cmTC_f5a77.dir/flags.make' has modification time 0,26 s in the future
Building CXX object CMakeFiles/cmTC_f5a77.dir/cm_cxx_make_unique.cxx.o
/usr/bin/g++ -O2 -std=gnu++17 -o CMakeFiles/cmTC_f5a77.dir/cm_cxx_make_unique.cxx.o -c /home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/Source/Checks/cm_cxx_make_unique.cxx
Linking CXX executable cmTC_f5a77
/home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/cmTC_f5a77.dir/link.txt --verbose=1
/usr/bin/g++ -O2 -L/home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/host/lib -Wl,-rpath,/home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/host/lib CMakeFiles/cmTC_f5a77.dir/cm_cxx_make_unique.cxx.o -o cmTC_f5a77
make[3]: warning: Clock skew detected. Your build may be incomplete.
make[3]: Leaving directory '/home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/CMakeFiles/CMakeTmp'
make[2]: warning: Clock skew detected. Your build may be incomplete.
make[2]: Leaving directory '/home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/CMakeFiles/CMakeTmp'
Determining if compiler supports C++ unique_ptr failed with the following output:
Change Dir: /home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/make cmTC_02c6e/fast && make[2]: Entering directory '/home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/CMakeFiles/CMakeTmp'
make[2]: Warning: File 'Makefile' has modification time 0,27 s in the future
make -f CMakeFiles/cmTC_02c6e.dir/build.make CMakeFiles/cmTC_02c6e.dir/build
make[3]: Entering directory '/home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/CMakeFiles/CMakeTmp'
make[3]: Warning: File 'CMakeFiles/cmTC_02c6e.dir/flags.make' has modification time 0,26 s in the future
Building CXX object CMakeFiles/cmTC_02c6e.dir/cm_cxx_unique_ptr.cxx.o
/usr/bin/g++ -O2 -std=gnu++17 -o CMakeFiles/cmTC_02c6e.dir/cm_cxx_unique_ptr.cxx.o -c /home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/Source/Checks/cm_cxx_unique_ptr.cxx
Linking CXX executable cmTC_02c6e
/home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/cmTC_02c6e.dir/link.txt --verbose=1
/usr/bin/g++ -O2 -L/home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/host/lib -Wl,-rpath,/home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/host/lib CMakeFiles/cmTC_02c6e.dir/cm_cxx_unique_ptr.cxx.o -o cmTC_02c6e
make[3]: warning: Clock skew detected. Your build may be incomplete.
make[3]: Leaving directory '/home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/CMakeFiles/CMakeTmp'
make[2]: warning: Clock skew detected. Your build may be incomplete.
make[2]: Leaving directory '/home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/CMakeFiles/CMakeTmp'
I cannot figure out wath is wrong.
I thought it could be a clock skew problem but I tried also outside a virtual machine with identical results.
I also tried to compile and link by hand without any errors or warnings.
/usr/bin/g++ -O2 -std=gnu++17 -o cm_cxx_make_unique.cxx.o -c /home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/build/host-cmake-3.15.5/Source/Checks/cm_cxx_make_unique.cxx
/usr/bin/g++ -O2 -L/home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/host/lib -Wl,-rpath,/home/max/Lavori/nova/srcs/repo/dep-startup/buildroot-output/buildroot-2020.02.1/output/host/lib cm_cxx_make_unique.cxx.o -o cmTC_f5a77
I also tried to run the binary without errors.
So even more 'I can not figure out what is wrong
Has same error when use Linux virtual machine (VMware) and when sources placed in shared folder. When move sources to user folder all configured successfully.
I'm trying to install R3.1.1 from sources on CentOS 6.5.
The .configure raises the following error
(...)
checking whether we can compute C Make dependencies... yes, using $(CC) -MM
checking whether gcc -std=gnu99 supports -c -o FILE.lo... yes
checking for gcc -std=gnu99 option to support OpenMP... -fopenmp
checking how to get verbose linking output from gfortran... -v
checking for Fortran 77 libraries of gfortran... -L/usr/local/lib64 -L/cm/shared/apps/slurm/14.03.0/lib64/../lib64 -L/cm/shared/apps/gcc/4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2 -L/cm/shared/apps/gcc/4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/cm/shared/apps/slurm/14.03.0/lib64/slurm -L/cm/shared/apps/slurm/14.03.0/lib64 -L/cm/shared/apps/gcc/4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../.. -lgfortran -lm -lquadmath
checking how to get verbose linking output from gcc -std=gnu99... -v
checking for C libraries of gcc -std=gnu99... -L/usr/local/lib64 -L/cm/shared/apps/slurm/14.03.0/lib64/../lib64 -L/cm/shared/apps/gcc/4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2 -L/cm/shared/apps/gcc/4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/cm/shared/apps/slurm/14.03.0/lib64/slurm -L/cm/shared/apps/slurm/14.03.0/lib64 -L/cm/shared/apps/gcc/4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../.. -lgcc_s
checking for dummy main to link with Fortran 77 libraries... none
checking for Fortran 77 name-mangling scheme... lower case, underscore, no extra underscore
checking whether gfortran appends underscores to external names... yes
checking whether gfortran appends extra underscores to external names... no
checking whether mixed C/Fortran code can be run... configure: WARNING: cannot run mixed C/Fortran code
configure: error: Maybe check LDFLAGS for paths to Fortran libraries?
gfortran was installed using yum
gfortran --version
GNU Fortran (GCC) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
I've no idea what I should put in LDFLAGS to fix that error.
UDPATE:
# find / -name "libgfor*.so"
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgfortran.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgfortran.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgfortran.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgfortran.so
/cm/shared/apps/gcc/4.8.2/lib64/libgfortran.so
/cm/shared/apps/gcc/4.8.2/lib/libgfortran.so
/cm/images/default-image/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgfortran.so
/cm/images/default-image/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgfortran.so
.
# tail config.log
#define SIZEOF_LONG_LONG 8
#define SIZEOF_DOUBLE 8
#define SIZEOF_SIZE_T 8
#define HAVE_LONG_DOUBLE 1
#define SIZEOF_LONG_DOUBLE 16
#define F77_FUNC(name,NAME) name ## _
#define F77_FUNC_(name,NAME) name ## _
#define HAVE_F77_UNDERSCORE 1
configure: exit 1
Try to locate libgfortran.so in your system and provide the path -Lthe_path -lgfortran or set the respective environment variables. If that does not help, try to find more details in the config.log (or similar) file to find out what does the configure actually try to do in that check.
Your gfortran reports it is version 4.8.2 but the libraries are from version 4.4.4. Try to locate (by which) which gfortran binary you run and where are its libraries. Try running the locate command for libgfortran.
Blockquote
Hello, I am trying to compile the latest source of The Powder Toy but my compiler (G++ with scons) is crashing every time it hits a command with --m in it.
Crash log:
scons --lin --release --sse2
scons: Reading SConscript files ...
Checking for C library fftw3f... (cached) yes
Checking for C library bz2... (cached) yes
Checking for C library z... (cached) yes
Checking for C header file bzlib.h... (cached) yes
Checking for C library lua... (cached) no
Checking for C library lua5.1... (cached) yes
scons: done reading SConscript files.
scons: Building targets ...
^[[Ag++ -o build/src/Format.o -c -w -std=c++98 -fkeep-inline-functions -sse2 -O3 -ftree-vectorize -funsafe-math-optimizations -ffast-math -fomit-frame-pointer -funsafe-loop-optimizations -Wunsafe-loop-optimizations -D_GNU_SOURCE=1 -D_REENTRANT -DLUACONSOLE -DGRAVFFT -D_GNU_SOURCE -DUSE_STDINT -D_POSIX_C_SOURCE=200112L -DUSE_SDL -DLIN -DX86 -DX86_SSE2 -I/usr/include/SDL -I/usr/include/lua5.1 -Ibuild/src -Ibuild/data -Ibuild/generated build/src/Format.cpp
g++: error: unrecognized option â-msse2â
scons: *** [build/src/Format.o] Error 1
scons: building terminated because of errors.
Why would this be happening? I've had to delete the -m32 command also to get it to compile.
I strongly suspect that it's because the -sse2 option is telling g++ to generate SSE2, which are SIMD instructions for Intel's x86 architecture. The Raspberry Pi board is a completely different computer architecture (ARM) and does not support SSE2. The ARM equivalent of SSE2 is NEON, but NEON is available for the ARM used in RPi.
I think that for options that g++ doesn't recognize, it tries prefixing with another flag (in this case -m, but I've seen -f before) to see if it's a synonym.
In your case sse2 makes no sense on the Raspberry Pi, and for the above example, is the problem.
What is ^[[A ? Do you have unprintable chars in your makefile? Can you echo all parameters one by one to identify which contains these strange characters?
So I was going to try playing around with run time code reloading, and IIRC plugins was the way to go.
But on my msys terminal, the compilation fails. Is this a package bug or I'm missing a dependency?
My GHC is from the latest Haskell platform, 7.4.1.
Thanks in advance.
Mdx#Bhmt ~
$ cabal install plugins
Resolving dependencies...
Configuring plugins-1.5.2.3...
configure: WARNING: unrecognized options: --with-compiler, --with-gcc
checking build system type... i686-pc-mingw32
checking for ghc... ghc
checking for value of __GLASGOW_HASKELL__... 704
checking for ghc library directory... C:\Program Files (x86)\Haskell Platform\20
12.2.0.0\lib
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for arc4random... no
checking for a BSD-compatible install... /usr/bin/install -c
configure: creating ./config.status
config.status: creating config.mk
config.status: creating testsuite/makewith/io/TestIO.conf
config.status: creating testsuite/makewith/unsafeio/Unsafe.conf
config.status: creating config.h
configure: WARNING: unrecognized options: --with-compiler, --with-gcc
Building plugins-1.5.2.3...
Preprocessing library plugins-1.5.2.3...
[ 1 of 12] Compiling System.Plugins.Process ( src\System\Plugins\Process.hs, dis
t\build\System\Plugins\Process.o )
[ 2 of 12] Compiling System.Plugins.Parser ( src\System\Plugins\Parser.hs, dist\
build\System\Plugins\Parser.o )
[ 3 of 12] Compiling System.Plugins.LoadTypes ( src\System\Plugins\LoadTypes.hs,
dist\build\System\Plugins\LoadTypes.o )
[ 4 of 12] Compiling System.Plugins.Consts ( src\System\Plugins\Consts.hs, dist\
build\System\Plugins\Consts.o )
src\System\Plugins\Consts.hs:39:23:
lexical error in string/character literal at character 'P'
cabal.exe: Error: some packages failed to install:
plugins-1.5.2.3 failed during the building phase. The exception was:
ExitFailure 1
You should update your ghc from 7.0.4 version.
I'm trying to compile the SndObj library from the source.
Supposedly it's as easy as just running 'scons' from the top of the SndObj directory.
I get this:
nhnifong#ubuntu-nate:~/SndObj-2.6.6$ scons
scons: Reading SConscript files ...
scons: warning: The Options class is deprecated; use the Variables class instead.
File "/home/nhnifong/SndObj-2.6.6/SConstruct", line 58, in <module>
scons: warning: The BoolOption() function is deprecated; use the BoolVariable() function instead.
File "/home/nhnifong/SndObj-2.6.6/SConstruct", line 60, in <module>
SndObj Library version is 2.6.5
Building the Sound Object Library
scons tools in this system: ['default', 'gnulink', 'gcc', 'g++', 'gfortran', 'gas', 'ar', 'filesystem', 'dvipdf', 'gs', 'jar', 'javac', 'javah', 'm4', 'rmic', 'rpcgen', 'swig', 'tar', 'zip']
Checking for Realtime IO support...
OS is Linux...
Checking for C header file alsa/asoundlib.h... (cached) no
Checking for C header file soundcard.h... (cached) no
Checking for C header file jack/jack.h... (cached) no
No alsa or OSS RT support
Host is little endian
swig exists...
Checking for C header file Python.h... (cached) no
Checking for C header file /usr/include/python2.6/Python.h... (cached) yes
Python version is 2.6
Checking for C header file m_pd.h... (cached) no
Checking for C header file ladspa.h... (cached) no
installing python module in /usr/lib/python2.6/dist-packages
scons: done reading SConscript files.
scons: Building targets ...
chmod a-x include/SndObj/*.h
scons: done building targets.
The first problem is that the C header files it claims are missing are all there in /usr/include/
The second problem is that the Python module is not actually installed in /usr/lib/python2.6/dist-packages
It looks like you have one or more config.cache files left over. Those should all be deleted and the installation restarted.