I have been using the Boost stacktrace library to print out a stacktrace of my program.
Boost 1.78.0
When compiling with pure C++ it compiles and my program prints the stacktrace nicely.
However when compiling with C++ /CLI, my program doesn't print the stacktrace.
Here is my reproducable example :
#include <boost/stacktrace.hpp>
#include <sstream>
#include <iostream>
#include <string>
int main() {
std::stringstream stack;
stack << boost::stacktrace::stacktrace();
std::string stacktrace = stack.str(); // The string "stacktrace" is empty when running with C++ CLI
std::cout << stacktrace;
}
Compiling this with C++ /CLI doesn't print the stacktrace to stdout, whereas compiling with pure C++ does print it to stdout.
Another thing is that when I use boost/stacktrace/stacktrace.hpp instead of boost/stacktrace.hpp my program fails to print the stacktrace even in pure C++.
Unfortunately, I couldn't find any references to this issue on stack overflow.
I am on Windows, and I'm using Visual Studio 2022.
I am using Boost version Version: 1.78.0.
I installed boost with vcpkg.
Thank you
I don't think Boost Stacktrace claims CLR support.
I'd expect some output, but not particularly useful output.
Of course, in CLR mode, you can use .NET stacktraces: https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.stacktrace?view=net-6.0
Another thing is that when I use boost/stacktrace/stacktrace.hpp instead of boost/stacktrace.hpp my program fails to print the stacktrace even in pure C++.
That's probably because that's not correct usage. There's many nuts and bolts to configuring the library correctly, see https://www.boost.org/doc/libs/1_79_0/doc/html/stacktrace/configuration_and_build.html. One of the possible configurations leads to no-op implementation.
Related
I'm trying to integrate CUDA to an existing aplication wich uses boost::spirit.
Isolating the problem, I've found out that the following code does not copile with nvcc:
main.cu:
#include <boost/spirit/include/qi.hpp>
int main(){
exit(0);
}
Compiling with nvcc -o cudaTest main.cu I get a lot of errors that can be seen here.
But if I change the filename to main.cpp, and compile again using nvcc, it works. What is happening here and how can I fix it?
nvcc sometimes has trouble compiling complex template code such as is found in Boost, even if the code is only used in __host__ functions.
When a file's extension is .cpp, nvcc performs no parsing itself and instead forwards the code to the host compiler, which is why you observe different behavior depending on the file extension.
If possible, try to quarantine code which depends on Boost into .cpp files which needn't be parsed by nvcc.
I'd also make sure to try the nvcc which ships with the recent CUDA 4.1. nvcc's template support improves with each release.
My problem is when debugging from Eclipse a program that uses Boost (even pure header) then the GDB debugger is unable to locate frame base for the function being trace into.
Please note that except this, the program works like a charm in debug and release mode. The problem is only for debugging and inspecting source code refering to Boost.
Please not also that the problem only affects OSX Yosemit.
The issue is that I can't see the value of the local variables. Below is the message I have in the "(x)= Variables" window of Eclipse :
Failed to execute MI command:
-data-evaluate-expression result
Error message from debugger back end:
Could not find the frame base for "main()".
The code is as simple as :
#include <boost/regex.hpp>
#include <iostream>
int main() {
int result = 1;
boost::regex reExpression("[a-z]+");
std::cout << "!!!Hello World !!!" << std::endl;
result ++;
cout << " Result = " << result << "\n";
return result;
}
The program is compiled using the command :
g++ -v -o -g bin/Essai-MACOS-Debug src/Essai.cpp -I/opt/local/include /opt/local/lib/libboost_regex-mt.a
If you remove the reference to Boost.Regex then everything is ok. I can inspect the value of the local variable result.
More interesting: I built a library with a single function relying on Boost, and call that function from main(). It happens that can inspect the code in main() and have the value of main's local variable but when I came inside the library's function, the one now referring to boost then again I can't see the local variables of that function.
So it seems that as soon as a source file is referring to Boost, GDB get confused.
I have installed GCC 4.9, GDB 7.7 and Boost 1.57 using MacPort on OSX Yosemit.
I've compile Boost from source with MacPort in order to use GCC instead of GCC using the command :
sudo port install -ns boost config.compiler=macport-gcc-4.9
I also tried with a version of Boost I compiled myself and I did have the same issue.
Does anyone knows about this problem ?
EDIT:
I've compiled and installed the last GDB version from sources (7.9) and have the same issue described here than with the 7.7.1 provided by MacPorts.
all.
Compiling simple stuff using the gcc toolchain for several years, today I ran against a curious phenomenon.
I installed Kubuntu 14.04 to a common desktop i686 machine with gcc 4.8.2 in it. But then, trying to build some well coded stuff pulled out from my local repository, I ran against tons of 'undefined reference to' messages. The code compiles, links und runs well under Ubuntu 11.04 / gcc 4.5.2.
I checked the linking process (by -Wl,--verbose to gcc), think it works. It finds all libraries I specify in the link command. An objdump -t myLib.so brings exactly the symbols I'd expect - but the linker doesn't see them.
Checking the pthread library also brings according symbols, except they are suffixed with some #GLIBC... stuff. Didn't check linker/loader tricks so far.
A sample like
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
static void *fooo (void *xxx) {
char *txt = (char*)xxx;
printf("My job is to print this :'%s'. Bye now!\n", txt);
return 0;
}
int main (int argc, char *argv[]) {
pthread_t thd;
pthread_create(&thd, NULL, fooo, "A POSIX thread");
sleep(1);
return 0;
}
runs very well on the old system just saying
gcc -l pthread fooo.c && ./a.out
but breaks at the linking step with 4.8.2.
Any idea would be very welcome.
.M
Thanks to sfrehse, JoachimPileborg et al!
Indeed, success depends on argument order. I knew this fact for static linking, but it is new in processing of shared objects with gcc.
Does someone know what the background of this improvement is? It breaks innumerable build processes, and I guess thousands of tomatoes are being made ready against gcc.gnu.org .....
.M
When I compile the following code containing the design C++11, in Windows7x64 (MSVS2012 + Nsight 2.0 + CUDA5.5), then I do not get errors, and everything compiles and works well:
#include <thrust/device_vector.h>
int main() {
thrust::device_vector<int> dv(10);
auto iter = dv.begin();
return 0;
}
But when I try to compile it under the Linux64 (Debian 7 Wheezey + Nsight Eclipse from CUDA5.5), I get errors:
../src/CudaCpp11.cu(5): error: explicit type is missing ("int"
assumed)
../src/CudaCpp11.cu(5): error: no suitable conversion function from
"thrust::detail::normal_iterator>" to "int"
exists
2 errors detected in the compilation of
"/tmp/tmpxft_00001520_00000000-6_CudaCpp11.cpp1.ii". make: *
[src/CudaCpp11.o] Error 2
When I added line:-stdc++11
in Properties-> Build-> Settings-> Tool Settings-> Build Stages-> Preprocessor options (-Xcompiler)
I get more errors:
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/stddef.h(432): error:
identifier "nullptr" is undefined
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/stddef.h(432): error:
expected a ";"
...
/usr/include/c++/4.8/bits/cpp_type_traits.h(314): error: namespace
"std::__gnu_cxx" has no member
"__normal_iterator"
/usr/include/c++/4.8/bits/cpp_type_traits.h(314): error: expected a
">"
nvcc error : 'cudafe' died due to signal 11 (Invalid memory
reference) make: * [src/CudaCpp11.o] Error 11
Only when I use thrust::device_vector<int>::iterator iter = dv.begin(); in Linux-GCC then I do not get an error. But in Windows MSVS2012 all c++11 features works fine!
Can I use C++11 in the .cu-files (CUDA5.5) in Windows7x64 (MSVC) and Linux64 (GCC4.8.2)?
You will probably have to split the main.cpp from your others.cu like this:
others.hpp:
void others();
others.cu:
#include "others.hpp"
#include <boost/typeof/std/utility.hpp>
#include <thrust/device_vector.h>
void others() {
thrust::device_vector<int> dv(10);
BOOST_AUTO(iter, dv.begin()); // regular C++
}
main.cpp:
#include "others.hpp"
int main() {
others();
return 0;
}
This particular answer shows that compiling with an officially supported gcc version (as Robert Crovella stated correctly) should work out at least for c++11 code in the main.cpp file:
g++ -std=c++0x -c main.cpp
nvcc -arch=sm_20 -c others.cu
nvcc -lcudart -o test main.o others.o
(tested on Debian 8 with nvcc 5.5 and gcc 4.7.3).
To answer your underlying question: I am not aware that one can use C++11 in .cu files with CUDA 5.5 in Linux (and I was not aware the shown example with host-side C++11 gets properly de-cluttered under MSVC). I even filed a feature request for constexpr support which is still open.
The CUDA programming guide for CUDA 5.5 states:
For the host code, nvcc supports whatever part of the C++ ISO/IEC
14882:2003 specification the host c++ compiler supports.
For the device code, nvcc supports the features illustrated in Code
Samples with some restrictions described in Restrictions; it does not
support run time type information (RTTI), exception handling, and the
C++ Standard Library.
Anyway, it is possible to use some of the C++11 features like auto in kernels, e.g. with boost::auto.
As an outlook, other C++11 features like threads may be quite unlikely to end up in CUDA and I heard no official plans about them yet (as of supercomputing 2013).
Shameless plug: If you are interested in more of these tweeks, feel free to have a look in our library libPMacc which provides multi-GPU grid and particle abstractions for simulations. We implemented lambda, a STL-like access concept for 1-3D matrices and other useful stuff there.
All the best,
Axel
Update: Since CUDA 7.0 C++11 support in kernels has been added officially. As BenC pointed our correctly, parts of this feature were already silently added in CUDA 6.5.
According to Jared Hoberock (Thrust developer), it seems that C++11 support has been added to CUDA 6.5 (although it is still experimental and undocumented). This may make things easier when starting to use C++11 in very large C++/CUDA projects, since splitting everything can be quite cumbersome for large projects when you use CMake for instance.
I wrote a c++ program using boost library in Xcode. Here is my code. It is very simple.
#include <iostream>
#include </usr/local/include/boost/math/special_functions/beta.hpp>
using namespace std;
using namespace boost::math;
int main (int argc, char * const argv[])
{
double a = 100.0;
double b = 100000.0;
double x = 0.3;
double result = beta(a, b, x);
cout << result << endl;
return 0;
}
But when I tried to build it in the Xcode, there popped up a lot of errors related to the library linking stuff. I noticed that the compiler that Xcode was using was "System Default: gcc 4.2". And all other options are gcc or LLVM gcc (I have no idea what this is).
I later tried to compile the file simply using terminal. Weird thing happened. If I compile it with g++, without any extra flags, the compilation completed successfully and the the program could be ran normally; but if I compile it with gcc, there are pages of errors.
So, to sum it up, while using g++, everything is OK; while using gcc, everything is not OK. Since the Xcode is using gcc, the program could not be compiled using Xcode.
(And I kind of need to use the Xcode because this is just a test program, I actually have a much bigger project to handle and I depend on the debugger of Xcode.)
So my question is, WHAT THE HELL is the difference between gcc and g++? Or how can I change the compiler of Xcode to g++?
gcc is a C compiler.
g++ is a C++ compiler.
You're trying to compile C++, ergo, you need to use a c++ compiler.
Googling "Using XCode for c++" brings up lots of results, but this one seemed fairly straightforward and had pictures:
https://www.cs.drexel.edu/~mcs171/Wi07/extras/xCode_Instructions/index.html
The gcc command compiles C files (although you can use -libstdc++) to link C++ files as well but I don't recommend it.
The g++ command works for C++ files which is why it worked in your case.
For XCode you have to change the compiler from GCC to G++ for it to successfully work.