gpuocelot llvm/Assembly/Parser.h: No such file or directory - c++

I am using ubuntu 12.04
I have been trying to install gpuocelot for a few day now.
I recently installed llvm from the svn using
svn co http://llvm.org/svn/llvm­project/llvm/trunk llvm
./configure ­­enable­optimized
sudo make
sudo make install
But to do this I had to update gcc to 4.7 which i had also done
Now when i run sudo ./build.py --install
I keep on getting the following error
ocelot/ocelot/ir/implementation/ExternalFunctionSet.cpp:28:34: fatal error: llvm/Assembly/Parser.h: No such file or directory
The following outputs might be of help
z
aid#zaid-lappy:~/gpuocelot$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2013 NVIDIA Corporation
Built on Wed_Jul_17_18:36:13_PDT_2013
Cuda compilation tools, release 5.5, V5.5.0
zaid#zaid-lappy:~/gpuocelot$ gcc --version
gcc (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04) 4.7.3
Copyright (C) 2012 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.
zaid#zaid-lappy:~/gpuocelot$ g++ --version
g++ (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04) 4.7.3
Copyright (C) 2012 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.
zaid#zaid-lappy:~$ echo $PATH
/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/l/checkout/gpuocelot/ocelot/build_local/lib:/usr/local/cuda-5.5/bin
echo $LD_LIBRARY_PATH
/usr/local/cuda-5.5/lib64:
echo $LIBRARY_PATH returns blank

The LLVM C++ API, including the very existence and location of headers, is very unstable. This is why projects usually align themselves to some official release of LLVM, and I'm sure GPUOcelot follows the same pattern.
In top-of-tree LLVM, the header llvm/Assembler/Parse.h doesn't exist, which is why you can't find it. You should compile & link GPUOcelot vs. the LLVM version it supports officially. If GPUOcelot tries to follow the top-of-tree of LLVM, at least there should be a "known good revision" with which it works.

Related

Can't cross-compile gdb with MinGW

I'm trying to cross-compile gdb so I could debug my Windows version of program.
My host system is Arch Linux(5.13.4-arch1-1 to be exact).
I'm using MinGW from the official repositories.
$ i686-w64-mingw32-gcc --version
i686-w64-mingw32-gcc (GCC) 11.2.0
Copyright (C) 2021 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.
I downloaded the source for gdb from https://ftp.gnu.org/gnu/gdb/ (gdb-10.2.tar.gz).
I unpacked it, cd into dir and ran:
$ ./configure --host=i686-w64-mingw32
$ make
For long it compiled without any errors and then:
CXX source-cache.o
source-cache.c:37:10: fatal error: srchilite/sourcehighlight.h: No such file or directory
37 | #include <srchilite/sourcehighlight.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
And also although compiler already compiled gdbserver and other different programs, I can't run them.
Launching gdbserver.exe with wine gives:
$ wine gdbserver.exe
0024:err:module:import_dll Library libgcc_s_dw2-1.dll (which is needed by L"Z:\\home\\udalny\\.local\\build\\gdb\\gdb-10.2\\gdbserver\\gdbserver.exe") not found
0024:err:module:import_dll Library libstdc++-6.dll (which is needed by L"Z:\\home\\udalny\\.local\\build\\gdb\\gdb-10.2\\gdbserver\\gdbserver.exe") not found
0024:err:module:LdrInitializeThunk Importing dlls for L"Z:\\home\\udalny\\.local\\build\\gdb\\gdb-10.2\\gdbserver\\gdbserver.exe" failed, status c0000135
Is it not statically linked?
Does anybody know how to fix it?
You can avoid the problem with the configure flag --disable-source-highlight if you can do without sourxe highlighting.

Running C/C++ code with VS code always throw "exited with code=1 in 0.123 seconds"

I am trying to set up VScode to be able to the "Code Runner" package for C and C++ code with the Code Runner package, but it would always error with:
[Running] cd "d:\Desktop\Programming\For_fun\tester\" && g++ practice.cpp -o practice && "d:\Desktop\Programming\For_fun\tester\"practice
[Done] exited with code=1 in 0.123 seconds
I have discovered that compiling and running with wsl and ubuntu would work, but regular command prompt wouldn't. I presume that is a big indicator of what the problem is, but I have no idea how to resolve it or even start googling.
I am on Windows 10
This is my code:
#include <vector>
#include <iostream>
#include <string>
using namespace std;
int main() {
cout << "Hello World!\n";
return 0;
}
And these are the results of me trying to confirm whether I have the relevant packages installed:
PS D:\Desktop\Programming\For_fun\tester> c++ --version
c++.exe (MinGW.org GCC Build-20200227-1) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
PS D:\Desktop\Programming\For_fun\tester> gcc --version
gcc.exe (Rev5, Built by MSYS2 project) 10.3.0
Copyright (C) 2020 Free Software Foundation, Inc.
PS D:\Desktop\Programming\For_fun\tester> g++ --version
g++.exe (MinGW.org GCC Build-20200227-1) 9.2.0
Copyright (C) 2019 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.
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Thanks!
It doesn't work. But I fixed the problem: Basically, I used the windows finder to find all instances of gcc.exe and deleted the folders within my program files that house them. Then I removed their paths from my environment variables. Finally, I did a clean reinstall of gcc-core and gcc-g++ through cygwin and it worked

Cannot cross-compile for arm with c++17

I am trying to cross-compile c++14/c++17 code for my raspberry pi. I am sure it worked on my old PC. However, when I try to compile it on my new pc, it returns me the following error.
$ arm-linux-gnueabihf-g++ main.cpp -std=c++17
arm-linux-gnueabihf-g++: error: unrecognized command line option ‘-std=c++17’
I thought it is the compiler issue, the version of the compiler I am using is:
$ arm-linux-gnueabihf-g++ --version
arm-linux-gnueabihf-g++ (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) 4.8.3 20140303 (prerelease)
Copyright (C) 2013 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.
I try to get the newest compiler with
sudo apt-get install libc6-armel-cross libc6-dev-armel-cross binutils-arm-linux-gnueabi libncurses5-dev build-essential bison flex libssl-dev bc
Yet, the version is still the same, which can only compile c++11.
How can I update the arm-linux-gnueabi-g++ compiler?? I am pretty sure there is a compiler that works since I used it before, but not sure how I get it.
I found the easiest way to solve this issue is to directly install the newest cross-compiler
sudo apt-get install g++-9-arm-linux-gnueabihf
and use the compiler as (just an example of using c++17)
arm-linux-gnueabihf-g++-9 main.cpp -std=c++17

arm-none-eabi-g++: error: CreateProcess: No such file or directory

I have a problem with arm-none-eabi-g++ compiler running on Windows.
When I run my makefile on Ubuntu, everything works fine.
Makefile target fails on Windows with error
arm-none-eabi-g++: error: CreateProcess: No such file or directory
I'm using MingGW on Windows. MinGW, make and G++ locations are added to Win PATH.
Compiler and make are the same versions on both OS.
Ubuntu
getconf ARG_MAX
2097152
arm-none-eabi-g++ --version
arm-none-eabi-g++ (GNU Tools for Arm Embedded Processors 7-2018-q3-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
Copyright (C) 2017 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.
make --version
GNU Make 4.1
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Windows 10 with MinGW
getconf ARG_MAX
32000
arm-none-eabi-g++ --version
arm-none-eabi-g++ (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
Copyright (C) 2017 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.
make --version
GNU Make 4.1
Built for i686-w64-mingw32
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
More information
This is how one of my makefile targets look like
$(PROJECT).o: $(PROJECT).cpp
#echo start of $(#F)
$(CPP) $(CC_FLAGS) #./.symbols.txt -std=gnu++11 -fno-rtti #./.includes.txt -o $# $<
#echo end of $(#F)
Interesting thing is, that Windows build works fine only if the size of .symbols.txt and .includes.txt combined is lower than 32k. So it might look like it depends on ARG_MAX size (which is on MINGW 32k), but it's probably not true. Because another target in the same makefile looks like
$(PROJECT).elf: $(SYS_OBJECTS)
$(file > .sys_objects.txt, $(SYS_OBJECTS))
$(LD) $(LD_FLAGS) -T$(LINKER_SCRIPT) $(LIBRARY_PATHS) -o $# #./.sys_objects.txt $(LIBRARIES) $(LD_SYS_LIBS) $(LIBRARIES) $(LD_SYS_LIBS)
and it works well on Windows despite that sys_objects.txt size is about 90k.
Both $(LD) and variables $(CPP) variables are set to arm-none-eabi-g++.
Another thing I have noticed is that something on Windows adds a file like C:\Users\user\AppData\Local\Temp\ccQWU5K6.s to the end of g++ command (regardless if it fails or not). I have no clue where does this come from (maybe some MINGW support argument?).
Has anyone a clue why build fails on Windows with arguments bigger than 32k even if another target works fine with big arguments? Maybe it might be a coincidence.

Unable to build C++ binary with -fvtable-verify

I am trying to enable vtable verification in my project. When I try to use the flag (-fvtable-verify=std) I get an error g++: error: -fvtable-verify=std is not supported in this configuration.
Can you help me figure out what is going wrong?
[root#eaf114bcd5cc build-debug]# g++ -fvtable-verify=std temp.cc
g++: error: -fvtable-verify=std is not supported in this configuration
[root#eaf114bcd5cc build-debug]# gcc --version
gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
Copyright (C) 2017 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.
[root#eaf114bcd5cc build-debug]# which gcc
/opt/rh/devtoolset-7/root/usr/bin/gcc