What I have:
I am writing Qt application for Linux (I work in Linx Mint 17.3 64-bit)
I use C++11 features in my Qt project (Qt ver 5.5)
I want to add libslave to my Qt project.
libslave uses deprecated (for C++11) boost::function, boost::shared_ptr, boost::bind and boost::any.
My trouble:
When I compile with gcc (v the whole project or only library with -std=c++11 flag boost crashes with many errors. Qt Creator shows about 4000 errors, but they are pretty similar and look like:
typedef boost::function< void( RecordSet& )> callback;
is not complete type
BOOST_NOEXCEPT'does not name a type
~any() BOOST_NOEXCEPT
etc...
I have tried to rewrite library with C++11 std library, but std does not containg boost::any analog, so that was bad idea.
Question:
How to compile boost (or at least libslave) with c++11?
Boost Version: 1.54 (from repo)
g++ version: 4.8.4 (from repo)
Qt version: 5.5 (downloaded from Official Site)
Linux Mint: 17.3 Rosa
UPDATE:
Example:
You can download code what I try to compile by this link.
Instruction:
Download tarball
Extract
Go to folder and just type make (all works fine)
Open MakeFile and replace CXX variable to
CXX = g++ -std=c++11
Try to make again and you'll get errors.
P.S.
To compile library you'll need libmysqld-dev, libboost-all-dev, libmysqlclient-dev.
Probably you'll need something else, but I don't remeber. Sorry.
I found the hack and it works for me.
I replace boost::bind usage in file nanomysql.h to std::bind by such strings:
...
typedef std::map<std::string, field> value_t;
typedef std::vector< value_t > result_t;
void store(result_t& out)
{
//You need specify template because of push_back has overloads
auto hack = std::bind<void(result_t::*)(const value_t&)>(&result_t::push_back, &out, _1);
use(hack);
}
...
And replace all boost::shared_ptr, boost::function to std::shared_ptr and std::function in all files in library.
After this everything compiles and work fine with -std=c++11 flag.
Whole code of nanomysql.h you can see here:
Link to code
Use actual fork of libslave - https://github.com/vozbu/libslave with support c++11. Support for mysql 5.6 and 5.7 will be soon
Related
I am new to Cuda, and I am trying to compile this simple test_1.cu file:
#include <stdio.h>
__global__ void kernel(void)
{
}
int main (void)
{
kernel<<<1,1>>>();
printf( "Hello, World!\n");
return 0;
}
using this: nvcc test_1.cu
The output I get is:
In file included from /usr/local/cuda/bin/../include/cuda_runtime.h:59:0,
from <command-line>:0:
/usr/local/cuda/bin/../include/host_config.h:82:2: error: #error -- unsupported GNU version! gcc 4.5 and up are not supported!
my gcc --version:
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
How can I install a second version of gcc (4.4 -) along with 4.6 without messing everything up?
I found this old topic:
CUDA incompatible with my gcc version
the answer was:
gcc 4.5 and 4.6 are not supported with CUDA - code won't compile and
the rest of the toolchain, including cuda-gdb, won't work properly.
You cannot use them, and the restriction is non-negotiable.
Your only solution is to install a gcc 4.4 version as a second
compiler (most distributions will allow that). There is an option to
nvcc --compiler-bindir which can be used to point to an alternative
compiler. Create a local directory and the make symbolic links to the
supported gcc version executables. Pass that local directory to nvcc
via the --compiler-bindir option, and you should be able to compile
CUDA code without effecting the rest of your system.
But I have no idea how to do it
In my case I didn't have root rights, so I couldn't fully replace the current gcc (4.7) with the older version 4.4 (which I think would be a bad alternative). Although I did have rights where CUDA was installed. My solution was to create an extra folder (e.g. /somepath/gccfornvcc/), wherever I had rights, then to create a link to an nvcc accepted compiler. I already had gcc 4.4 available (but you can install it, without removing your current version).
ln -s [path to gcc 4.4]/gcc-4.4 /somepath/gccfornvcc/gcc
Then, in the same folder where the nvcc binary lives, you should find a file called nvcc.profile . There you just need to add the following line:
compiler-bindir = /somepath/gccfornvcc
And that will make nvcc use the proper compiler. This helps keeping the system in a proper state, keeping the newest compiler, but nvcc (only nvcc) will use the old compiler version.
Doing some research online shows several methods for accomplishing this task. I just tested the method found here: http://www.vectorfabrics.com/blog/item/cuda_4.0_on_ubuntu_11.04 and it worked like a charm for me. It steps you through installing gcc 4.4 and creating scripts to run that version with nvcc. If you prefer trying the method mentioned in your post I'd recommend following that first link to install gcc4.4 and then create symbolic links as mentioned in your post. Creating symbolic links in Linux is accomplished by using the 'ln' command.
For example:
ln -s [source file/folder path] [linkpath]
This link gives a few examples of creating symbolic links on both Ubuntu and Windows: http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/. Hopefully that points you in the right direction.
I guess you may try the new, beta, version, that based on LLVM.
Another way to make nvcc work with non-default compiler (unlike #Sluml's answer, it allows more flexibility):
At first, just like #Slump proposed, you need to create directory ~/local/gcc-4.4/, and then create there symlinks for right versions of gcc: for i in gcc gxx; do ln -s /usr/bin/${i}-4.4 ~/local/cudagcc/${i}; done. Now when you run nvcc -ccbin ~/local/gcc-4.4/ ... nvcc will use correct versions of gcc.
Here is small CMake snippet of forcing nvcc use specific host compiler.
option (CUDA_ENFORCE_HOST_COMPILER "Force nvcc to use the same compiler used to compile .c(pp) files insted of gcc/g++" OFF)
if (${CUDA_ENFORCE_HOST_COMPILER})
set (CMAKE_GCC_TEMP_DIR "CMakeGCC")
file(MAKE_DIRECTORY ${CMAKE_GCC_TEMP_DIR})
execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ${CMAKE_C_COMPILER} ${CMAKE_GCC_TEMP_DIR}/gcc)
execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ${CMAKE_CXX_COMPILER} ${CMAKE_GCC_TEMP_DIR}/g++)
set(CUDA_NVCC_FLAGS -ccbin ${CMAKE_GCC_TEMP_DIR} ${CUDA_NVCC_FLAGS})
endif()
Referenceļ¼
I update my gcc from 4.4 to 4.6. Then I could not use nvcc to compile my code. Luckily, by using the method provided by the following link. I set my default gcc compiler back to gcc 4.4. Now, I could compile file using either gcc4.4 or gcc4.6. quit cool
http://ubuntuguide.net/how-to-install-and-setup-gcc-4-1g4-1-in-ubuntu-10-0410-10
I am trying to cabal install a component of wxHaskell (Haskell platform 2013.2 against wxWidgets 3.0).
I was able to compile the git version with 32 bit mingw from mingw.org. But in the end, the installed wx cannot function correct, and running a minimal example gives runtime exceptions in wxc.dll. So I try to compile the same thing under TDM-GCC 4.8.1 64bit, since the wxWidgets people provide their binary in the form of TDM-GCC compiled binaries.
But I immediately run into compilation errors with TDM-GCC, telling me
error: 'strnlen' was not declared in this scope
What surprises me is that even though both mingw32 and TDM-gcc uses the same external gcc from Haskell Platform c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe, one would give an error while the other compiles fine.
The first file causing problem is src\cpp\eljaccelerator.cpp. It compiles OK under mingw32:
...
c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe -Wl,--hash-size=31 -Wl,--reduce-
memory-overheads -Isrc/include -IC:/MinGW/msys/1.0/local/include/wx-3.0 -IC:/Min
GW/msys/1.0/local/lib/wx/include/msw-unicode-3.0 -D__WXMSW__ -DWXUSINGDLL -D_LAR
GEFILE_SOURCE=unknown -DwxcREFUSE_MEDIACTRL -DBUILD_DLL -c src\cpp\eljaccelerato
r.cpp -o dist\build\src/cpp/eljaccelerator.o
but gives an error under TDM-gcc:
Building wxc
c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe -Wl,--hash-size=31 -Wl,--reduce-
memory-overheads -Isrc/include -IC:/mingw/msys/1.0/local/include/wx-3.0 -IC:/min
gw/msys/1.0/local/lib/wx/include/msw-unicode-3.0 -D__WXMSW__ -DWXUSINGDLL -D_FIL
E_OFFSET_BITS=64 -DwxcREFUSE_MEDIACTRL -DBUILD_DLL -c src\cpp\eljaccelerator.cpp
-o dist\build\src/cpp/eljaccelerator.o
In file included from C:/mingw/msys/1.0/local/include/wx-3.0/wx/crt.h:19:0,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/string.h:4305,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/memory.h:15,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/object.h:19,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/wx.h:15,
from src/include/wrapper.h:20,
from src\cpp\eljaccelerator.cpp:1:
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h: In function 'size_t wxStrnlen
(const char*, size_t)':
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h:173:92: error: 'strnlen' was n
ot declared in this scope
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h: In function 'size_t wxStrnlen
(const wchar_t*, size_t)':
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h:187:95: error: 'wcsnlen' was n
ot declared in this scope
Failed to install wxc-0.90.1.1
I was wondering if anyone has any similar experience. Any idea what went wrong and how to fix compilation for TDM-GCC? I tried adding #include <cstring> to wxcrt.h but it doesn't change anything.
FYI, I have compiled wxWidgets 3.0.0 from source in mingw and tdm-gcc versions respectively, using
./configure --enable-stl && make && make install
I can provide more details if needed.
First of all, wxWidgets certainly does work with MinGW, the fact that only TDM binaries are provided simply means that someone volunteered to provide the latter but not the former. But all three popular versions of MinGW (the two already mentioned and MinGW-w64) do work, so there must be something wrong with the build...
However while they all work, they are certainly different compilers, so what do you mean that they both use the same gcc binary? It must be either a MinGW one or a TDM one, but it can't be both at once.
It's also very suspicious that the configure detects different flags to use for the large file support. Look at config.log, something must have gone wrong and there must be some errors in the initial stage in it.
I try to crosscompile some c++11 source with mingw on linux for windows. The code uses std::thread.
When i compile i always get some errors:
$ ../mingw/cross/bin/i686-w64-mingw32-g++ -std=c++11 -I include/ test.cpp -lstdthread -otest
In file included from test.cpp:4:0:
...
error: 'thread' in namespace 'std' does not name a type
...
I it possible to enable c++11 threads in mingw? The code compiles without any problems with the local g++.
Thank you,
regars
Kevin
-edit-
I just downloaded the mingw somewhere in the internet, because i tried to get an as new as possible version:
../mingw/cross/bin/i686-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=../mingw/cross/bin/i686-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/home/bmeier/source/mingw/cross/bin/../libexec/gcc/i686-w64-mingw32/4.8.1/lto-wrapper
Target: i686-w64-mingw32
Configured with: /home/drangon/work/mingw-w64-dgn_32/source/gcc-4.8.1/configure --target=i686-w64-mingw32 --disable-nls --disable-multilib --with-gmp=/home/drangon/work/mingw-w64-dgn_32/build/for_cross --with-mpfr=/home/drangon/work/mingw-w64-dgn_32/build/for_cross --with-mpc=/home/drangon/work/mingw-w64-dgn_32/build/for_cross --with-isl=/home/drangon/work/mingw-w64-dgn_32/build/for_cross --with-cloog=/home/drangon/work/mingw-w64-dgn_32/build/for_cross --enable-languages=c,c++,objc,obj-c++ --disable-libstdcxx-pch --prefix=/home/drangon/work/mingw-w64-dgn_32/cross --with-sysroot=/home/drangon/work/mingw-w64-dgn_32/cross
Thread model: win32
gcc version 4.8.1 (GCC)
regards
Kevin
There is already a native implementation of std::thread and sync primitives, that works with any C++11 version of MinGW:
https://github.com/meganz/mingw-std-threads
Basically MinGW does not support threads on windows see the following link: http://www.cplusplus.com/forum/windows/82461/
Specifically _GLIBCXX_HAS_GTHREADS is not defined and the class thread in the header thread requires it. (It is built on gthreads).
You should try and use boost::thread for a win/linux compatible thread class
Most probably you might have forgot to include thread header #include <thread>
I am new to Cuda, and I am trying to compile this simple test_1.cu file:
#include <stdio.h>
__global__ void kernel(void)
{
}
int main (void)
{
kernel<<<1,1>>>();
printf( "Hello, World!\n");
return 0;
}
using this: nvcc test_1.cu
The output I get is:
In file included from /usr/local/cuda/bin/../include/cuda_runtime.h:59:0,
from <command-line>:0:
/usr/local/cuda/bin/../include/host_config.h:82:2: error: #error -- unsupported GNU version! gcc 4.5 and up are not supported!
my gcc --version:
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
How can I install a second version of gcc (4.4 -) along with 4.6 without messing everything up?
I found this old topic:
CUDA incompatible with my gcc version
the answer was:
gcc 4.5 and 4.6 are not supported with CUDA - code won't compile and
the rest of the toolchain, including cuda-gdb, won't work properly.
You cannot use them, and the restriction is non-negotiable.
Your only solution is to install a gcc 4.4 version as a second
compiler (most distributions will allow that). There is an option to
nvcc --compiler-bindir which can be used to point to an alternative
compiler. Create a local directory and the make symbolic links to the
supported gcc version executables. Pass that local directory to nvcc
via the --compiler-bindir option, and you should be able to compile
CUDA code without effecting the rest of your system.
But I have no idea how to do it
In my case I didn't have root rights, so I couldn't fully replace the current gcc (4.7) with the older version 4.4 (which I think would be a bad alternative). Although I did have rights where CUDA was installed. My solution was to create an extra folder (e.g. /somepath/gccfornvcc/), wherever I had rights, then to create a link to an nvcc accepted compiler. I already had gcc 4.4 available (but you can install it, without removing your current version).
ln -s [path to gcc 4.4]/gcc-4.4 /somepath/gccfornvcc/gcc
Then, in the same folder where the nvcc binary lives, you should find a file called nvcc.profile . There you just need to add the following line:
compiler-bindir = /somepath/gccfornvcc
And that will make nvcc use the proper compiler. This helps keeping the system in a proper state, keeping the newest compiler, but nvcc (only nvcc) will use the old compiler version.
Doing some research online shows several methods for accomplishing this task. I just tested the method found here: http://www.vectorfabrics.com/blog/item/cuda_4.0_on_ubuntu_11.04 and it worked like a charm for me. It steps you through installing gcc 4.4 and creating scripts to run that version with nvcc. If you prefer trying the method mentioned in your post I'd recommend following that first link to install gcc4.4 and then create symbolic links as mentioned in your post. Creating symbolic links in Linux is accomplished by using the 'ln' command.
For example:
ln -s [source file/folder path] [linkpath]
This link gives a few examples of creating symbolic links on both Ubuntu and Windows: http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/. Hopefully that points you in the right direction.
I guess you may try the new, beta, version, that based on LLVM.
Another way to make nvcc work with non-default compiler (unlike #Sluml's answer, it allows more flexibility):
At first, just like #Slump proposed, you need to create directory ~/local/gcc-4.4/, and then create there symlinks for right versions of gcc: for i in gcc gxx; do ln -s /usr/bin/${i}-4.4 ~/local/cudagcc/${i}; done. Now when you run nvcc -ccbin ~/local/gcc-4.4/ ... nvcc will use correct versions of gcc.
Here is small CMake snippet of forcing nvcc use specific host compiler.
option (CUDA_ENFORCE_HOST_COMPILER "Force nvcc to use the same compiler used to compile .c(pp) files insted of gcc/g++" OFF)
if (${CUDA_ENFORCE_HOST_COMPILER})
set (CMAKE_GCC_TEMP_DIR "CMakeGCC")
file(MAKE_DIRECTORY ${CMAKE_GCC_TEMP_DIR})
execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ${CMAKE_C_COMPILER} ${CMAKE_GCC_TEMP_DIR}/gcc)
execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ${CMAKE_CXX_COMPILER} ${CMAKE_GCC_TEMP_DIR}/g++)
set(CUDA_NVCC_FLAGS -ccbin ${CMAKE_GCC_TEMP_DIR} ${CUDA_NVCC_FLAGS})
endif()
Referenceļ¼
I update my gcc from 4.4 to 4.6. Then I could not use nvcc to compile my code. Luckily, by using the method provided by the following link. I set my default gcc compiler back to gcc 4.4. Now, I could compile file using either gcc4.4 or gcc4.6. quit cool
http://ubuntuguide.net/how-to-install-and-setup-gcc-4-1g4-1-in-ubuntu-10-0410-10
For some reason, I should use gcc to compile a C file, then link against Visual C++ 2008 project.
(I used the current latest gcc version: cygwin gcc 4.3.4 20090804.)
But there is one problem: gcc always allocate a big array with _alloca,
and VC linker can't resolve the symbol __alloca.
for example,
int func()
{
int big[10240];
....
}
this code makes the _alloca dependency although I didn't call the _alloca function explicitly.
(array size matters. if i change 10240 -> 128, everything ok)
I tried gcc option -fno-builtin-alloca or -fno-builtin, but no luck.
Is it possible to make gcc not to use _alloca ? (or adjust the threshold?)
Best thing to do would be to compile all code with VC++. If that's not possible..
You should use the mingw gcc instead of the cygwin one. It's designed to output code that will be linked against the VC++ runtime, not the cygwin libraries. In particular, it will call the VC++ runtime function __chkstk instead of __alloca.
You could just write your own _alloca routine and link against that. Look at the gcc library source to see what it's supposed to do.
It looks like _alloca has been deprecated by Microsoft and is no longer in their runtime libraries after VS2005. Newer runtime libraries support _malloca.
Your options don't look good. You can try to build with VS2005 instead. Perhaps cygwin has an option where you can tell it you are using a newer runtime library (and if they don't support that yet, you could file it as a feature request).
some related discussions:
cygwin: gcc and alloca
GNU Compiler Collection (GCC) Internals
gcc and alloca