This seems to be a recurring issue.
I use a combination of CUDA and Boost libraries. The works fine e.g. for some Boost libraries. If I try to include boost/math/special_functions.hpp, I get errors like:
argument of type "_v1di" is incompatible with parameter of type
"_attribute((vector_size(8))) long"
Any advice would be helpful
NVCC support in boost is still unstable. Most heavy TMP based code are susceptible to failure. As a maintainer of the NVCC support in boost, i urge you to report the error to the Boost SVN Trac so we can handle it
This is not a direct answer to solve this specific problem, but a more general one. I'm assuming here you use NVCC to compile your code which includes the Boost header. Passing heavily templated code through NVCC sometimes causes problems. Make sure you're using the very latest version of NVCC. Template support keeps improving and you might just get lucky with an update.
Otherwise, you might want to devise a way to split your code into a part using Boost which won't need to go through NVCC and CUDA specific code which does.
Related
So I have enabled -fsantize=address to write a good program.
However, quite a bit of issues was being caught by other libraries that are not written by me (for ex, /lib64/...so)
I looked into -fsantize-blacklist option but seems like it's only available for clang not for GCC.
I know you can blacklist specific functions in your source code. But to be honest, that is not the ideal way as I wouldn't know which function will cause the issue ahead of time.
Is there any way to prevent GCC from processing address sanitizer for files under a specific folder?
Please help :(
Unfortunately fsanitize-blacklist has been rejected by GCC maintainers several times and there's no equivalent option. You could add Clang support or use -fsanitize-recover=address together with export ASAN_OPTIONS=log_path=path/to/logs to collect errors from all libraries and then filter the ones that are relevant.
I'm using an external preprocessor (pyexpander) for my cross-platform/cross-IDE c++ project*. GCC already works nicely with the -no-integrated-cpp -B${PWD} option. I could manually preprocess each file into a specific temp dir, then compile the processed files. But is there a better way? Specifically, I'd love to hook the native preprocessors so IDE-level code analysis is happy (code completion and error checking). Any hints how I can achieve this would be much appreciated.
*"But why not use c++ macros?" They can't do macro-macros and I need that.
*"But why not use m4?" Because python happens to already be a requirement for this codebase, and m4 seems to not come with MSVS and thus would be yet another requirement/point of failure. I would still have to resolve the original preprocessor problem.
*"But why not use language something_better?" Because I have no choice in the matter. (Though I would love to use nim all the way!!)
Here's the issue: the code I'm using uses a big library which links against boost. When I compile with static linking, everything works fine. However, when I try dynamic linking I get a bunch of undefined reference errors. The first thought was obviously "I am not linking the boost program_options" library, but I looked, and it is there in the linking command (and it comes after the library that needs it). Among the different errors, though, this stood out:
undefined reference to `_ZN5boost15program_options3argB5cxx11E
In my daily experience, linking errors are usually of the form "undefined reference to somefunction(...)". So I went to the installation folder of my boost library and used readelf to see what symbols I have in the library libboost_program.so. And in fact, that symbol does not appear. Instead, the closest I found is _ZN5boost15program_options3argE.
Google-ing a little bit, I found out that the extra part B5cxx11 is a new addition to the name mangling since C++11. It appears that boost (at least version 1.59.0) does not yet support this new name mangling.
So my question is: Is this a known issue? What workaround are there? And why does this issue not show up with static linking?
Edit: In case someone stumbles on this question in the future, I just tried boost 1.60.0, and the symbols contain the string B5cxx11. I believe (read: hope) this will solve the issue. As a double check, though, I am going to recompile again boost 1.59.0 to see if this is due to something I changed in my environment (although I doubt it).
This question was asked many moons ago, but since I already landed on this page I will pitch in with a possible solution.
You could try to compile your code with the -D_GLIBCXX_USE_CXX11_ABI=0 flag or define this macro: #define _GLIBCXX_USE_CXX11_ABI 0. See answers for this question for more details.
It's not that boost has to support it, your compiler/linker has. Probably your library was compiled with C++11 support and so was your boost, but your current program isn't. Try with the --std=c++11 option if you're on GCC.
Or maybe it's the other way around, and you're instantiating a template in your C++11 which uses C++11 name mangling and can't find library functions in the non-C++11-compiled boost (though that would border on compiler bug).
I have a similar problem recently. I recompile my boost library using the following commands
./b2 --build-dir=build/x86 address-model=32 threading=multi --toolset=gcc --layout=versioned --stagedir=./stage/x86 -j 8
./b2 --build-dir=build/x64 address-model=64 threading=multi --toolset=gcc --layout=versioned --stagedir=./stage/x64 -j 8
Then compile my program using
g++ main.cpp -L/home/research/boost_library/boost_1_68_0/stage/x64/lib/ -lboost_program_options-gcc82-mt-x64-1_68
This solves my problem. I am using gcc 8.2 on redhat linux
We have Oracle 11 running on HP-UX 11.31 and gcc 4.4.3. It seems that there is no way to link to occi, because it was built with aCC. Is there any workaround for this?
I had the silly idea that I could somehow build a library that basically proxied the connection - build the library with aCC in some way that could be linked to by gcc. Is this possible?
No, there isn't a way around that.
Different C compilers have interchangeable code using a standard ABI. You can mix and match their object code more or less with impunity.
However, different C++ compilers have a variety of different conventions that mean that their object code is not compatible. These relate to class layout (especially in multiple inheritance hierarchies and the dreaded 'diamond-of-death'), but also in name mangling conventions and exception handling. The name mangling schemes are deliberately made different so that you cannot accidentally link objects from one compiler with another.
Generally, if libraries are built using a C++ compiler, you have to link your code using the same - or at least a compatible - C++ compiler. And that almost invariably means a compiler from the same family. For example, you might be able to use G++ 4.5.0 even if the code was built with G++ 4.4.2. However, you won't be able to mix aCC with G++.
I'm trying to migrate a project which uses Boost (particularly boost::thread and boost::asio) to VxWorks.
I can't get boost to compile using the vxworks gnu compiler. I figured that this wasn't going to be an issue as I'd seen patches on the boost trac that purport to make this possible, and since the vxworks compiler is part of the gnu tool chain I should be able to follow the directions in the boost docs for cross compilation.
I'm building on windows for a ppc vxworks.
I changed the user-config.jam file as specified in the boost docs, and used the target-os=linux option to bjam, but bjam appears to hang before it can compile. Closer inspection of the commands issued by bjam (by invoking it using the -n option) reveal that it's trying to compile with boost::thread's win32 files. This can't be right, as vxworks uses pthreads.
My bjam command: .\bjam --with-thread toolset=gcc-ppc target-os=linux gcc-ppc is set in user-config to point to the g++ppc vxworks cross compiler.
What am I doing wrong? I believe I have followed the docs to the letter.
If it's #including win32 headers instead of the pthread ones, there could be a discrepancy between the set of macros your compiler is defining and the macros the boost headers are checking for. I had a problem like that with the smart pointer headers, which in an older version of boost would check for __ppc but my compiler defined __ppc__ (or vice versa, can't remember).
touch empty.cpp
ccppc -dD -E empty.cpp
That will show you what macros are predefined by your compiler.
I never tried to compile boost for VxWorks, since I only needed a few of the headers.
Try also adding
threadapi=pthread
The documentation you mention is for Boost.Build -- which is standalone build tool -- and the above flag is something specific to Boost.Thread library. What do you mean by "hang"? Because Boost libraries are huge, it sometimes take a lot of time to scan dependencies prior to build.
If it actually hangs, can you catch bjam in a debugger and produce a backtrace? Also, log of any output will help.