Forum Discussion
Hello again, I have finally had time to do some more testing and debugging. Unfortunately, my claim that it works perfectly is not correct. My projects appear to run properly when i++ is run with –march=”x86-64” but not with any FPGA architecture. This somewhat surprised me because I thought it would behave the same for the parts of the code that are not part of a component function.
I included my example projects in the tar file and a partially completed tutorial pdf (please excuse the lack of polish since the tutorial is not my concern right now). All of the code is well commented and not very large.
To recap, my goal is to have a simple project to showcase how gtest and cmake could work with with the i++ compiler.
I would appreciate it if someone who knows more about what i++ does behind the scenes could shed some light on what is happening. I tried to document in the tutorial everything necessary to duplicate my setup. I believe that the issue is that libstdc++ is not linked against properly, or some such thing. The funky installation of the gcc 5.4.0 that intelFPGA recommends could also have something to do with that.
(Note this is conjecture that doesn’t have bulletproof reasoning because my understanding of the situation is a little shody.)
Nonetheless, here is some of my justification for my thoughts:
This is my output from “cmake3 ..” It confuses me that the CXX identification is Clang and not g++. I worry this may actually be the culprit, but I’m not entirely sure how to test that at the moment.
cmake3 ..
-- The C compiler identification is GNU 4.8.5
-- The CXX compiler identification is Clang 6.0.1 <===========================
-- Check for working C compiler: /bin/cc
-- Check for working C compiler: /bin/cc -- 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: /…/intelFPGA_pro/18.1/hls/bin/i++
-- Check for working CXX compiler: /…/intelFPGA_pro/18.1/hls/bin/i++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features – failed <===============================
-- Found GTest: /usr/lib64/libgtest.so
-- Configuring done
-- Generating done
This is my output from running make afterwards:
LMemSplit: Unable to resolve split destination type on:
_ZTVN10__cxxabiv120__si_class_type_infoE
Compiler Error: Cannot resolve destination address space through pointer indirection.
HLS Main Optimizer FAILED.
make[2]: *** [x86] Error 1
make[1]: *** [CMakeFiles/x86.dir/all] Error 2
make: *** [all] Error 2
“Researching” on stack overflow, this _ZTVN10__cxxabiv120__si_class_type_infoE is what I’ve based my assumptions on.
I’ve found that errors involving this string tend to involve not linking properly to “libstdc++” I tried to explicitly link to the appropriate shared library in the gcc 5.4.0 installation, but I did not have much luck with this.
This link gave me some useful information about what the above gibberish is actually referring to:
http://refspecs.linuxfoundation.org/LSB_3.1.0/LSB-CXX-generic/LSB-CXX-generic/libstdcxx-ddefs.html