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.
Related
I have compiled the very simple program
$ cat main.cpp
#include <iostream>
int main() {
uint64_t val=1;
// val = htobe64(val);
std::cout << val << std::endl;
}
$ g++ -g main.cpp -o a.out
When I debug it using cgdb I get the following:
$ cgdb a.out
But when I uncomment the line // val = htobe64(val) something strange happens:
$ cat main.cpp
#include <iostream>
int main() {
uint64_t val=1;
val = htobe64(val);
std::cout << val << std::endl;
}
$ g++ -g main.cpp -o a.out
$ cgdb a.out
Uncommenting this single line causes cgdb to start showing the splash screen and when I type start as in the screenshot it only gives me assembler code (before cgdb started directly showing the source code and not its splash screen). Furthermore somehow the file path /home/user/byteswap.h appears in the screenshot, but this file does not exist (In this example user is was my username and /home/user my working directory).
Can someone tell me what is happening here and what I can do to be able to debug a program that is calling htobe64, i.e. how to achieve that cgdb will show me the source code as in the first example at the top?
Here are the tool versions:
$ cgdb --version
CGDB 0.7.1
Copyright 2002-2019 Bob Rossi and Mike Mueller.
CGDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
There is absolutely no warranty for CGDB.
$ gdb --version
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 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.
$ g++ --version
g++ (Debian 11.2.0-10) 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.
When posting this questions I became aware of the fact that my g++ version is very new compared to my gdb version (I recently updated it to have better C++20 support).
I turns out that updating the gdb version solved the problem: With gdb version GNU gdb (Debian 10.1-2) 10.1.90.20210103-git the problem is no longer present. I admit that I should have verified this before posting but I do not delete the question because it may help others having similar strange obervations.
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
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
I recently upgraded Linux to
GCC 6.4 version(/usr/local/gcc-6.4.0/lib/gcc/x86_64-pc-linux-gnu/6.4.0)
old version 4.6(/usr/lib/gcc/x86_64-redhat-linux/4.6.2)
However, the gcc path has not changed in R studio.
I tried to change using Sys.setenv(PKG_CXXFLAGS="-std=c++11"),
but it is not still working.
what should I do?
[linux]$ gcc --version
gcc (GCC) 6.4.0
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.
R studio
system2("gcc", "--version")
gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-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.
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/llvmproject/llvm/trunk llvm
./configure enableoptimized
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.