The video about Red and Red/System shows the compilation process in which Red is compiled to Red/System.
Youtube: https://youtu.be/-KqNO_sDqm4?t=27m12s
I know how to compile Red code with the -c option. Is there a way to output the Red/System code that is created during the compilation process?
The README mentions --red-only, and says:
"Stop just after Red-level compilation. Use higher verbose level to see compiler output. (internal debugging purpose)"
According to #jck this also requires -c for compiling and verbosity level 1:
./red -c --red-only -v 1
Related
I am currently trying to write a GCC backend for a new architecture, but when I try to compile it I get the following error message:
xgcc: internal compiler error: Segmentation fault signal terminated program cc1
The build is configured with the following command:
../gcc/configure --prefix=--prefix=$HOME/GCC-10.0.1 --disable-bootstrap --target=arch_name --enable-languages=c
How would I go about fixing this error so that I can build my backend?
As far as I am aware, I have implemented the target macro's, functions and insn patterns required to get GCC to build.
Sorry that the question is a bit vague, I am not sure what extra information I can provide. If more specific information is needed please let me know and I will edit the question.
Thanks in advance.
How would I go about fixing this error so that I can build my backend?
Debug cc1.
xgcc is located in $builddir/gcc. Hence run $builddir/xgcc -B$builddir -v -save-temps <options-that-crash-cc1>.
xgcc -v ... will print the sub-commands it is calling, record the options it supplies to the crashing cc1 call.
Run a debugger against that cc1 call, supply the right options and put a breakpoint at abort (will be fancy_abort) actually.
Build the compiler without optimization. It's enough to run make in $builddir/gcc for that. You can supply additional option if you like, e.g. make -j4 cc1 CXXFLAGS='<flags-to-pass>'.
$builddir/gcc provides .gdbinit to augment gdb with additional hooks to improve debugging experience.
I am attempting to build an application using g++ that is composed of several source files and also uses OpenCV 3.1.0.
The CMD command is:
g++ -o home_surveillance -static -std=c++11 -m64 -IC:\Tools\OpenCV\opencv\build\include -LC:\Tools\OpenCV\opencv\build\x64\vc14\lib -lopencv_world310 configuration_manager.cpp events.cpp image_processor.cpp main.cpp response_module.cpp scheduler.cpp
The error produced is:
C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lopencv_world310
collect2.exe: error: ld returned 1 exit status
I have been trying various things and searching for answers for a couple days now. I should note that the application builds properly in Visual Studio 2015. I have tried compiling the source files using g++ with the -c option and they all seem to compile fine. It is just the linking phase that produces an error.
Things I have tried:
Just about every possible combination of the specified command. (Modifying order of the options, -lopencv_world310.a, -lopencv_world310.lib, -lopencv_world310, -l"full_path"+"opencv_world310", etc..)
Checked that all the paths and filenames are correct.
Reinstalled mingw to make sure I was using mingw-w64 since this is a 64-bit application.
Running CMD as admin thinking maybe CMD could not access the path specified with -L option.
Googling and reading every post I could find. (Most posts about "ld.exe cannot find "library_name" are a result of someone using "library_name".a or "library_name".lib as input to the -l option).
Reading mingw documentation on the use of GCC/g++ to ensure I wasn't missing anything obvious.
Praying to Bjarne Stroustrup.
Ritual sacrifice involving a Pentium 2.
I am building boost on my windows using mingw-4.8.1 and have a few targets which failed. My Problem is that, I do not know which specific targets failed and which were skipped.
Is there a way to list the failed/skipped targets after the build is completed?
Here the console output:
...failed updating 20 targets...
...skipped 28 targets...
...updated 5789 targets...
Commands used after downloading a unzipping boost:
bootstrap
once b2.exe is built. I execute the following command in cmd
b2 -j4 --build-dir=build toolset=gcc --build-type=complete --stagedir=C:\SW\Boost -sNO_BZIP2=1
System: Windows 7 ( intel i5 vPro)
Compiler: gcc (mingw 4.8.1)
Boost: boost 1.61.0
I had the same problem. After some research, I found this is the best way to see where it got failed.
My error messages (depends on your machine, you may see different ones):
...failed updating 6 targets...
...skipped 6 targets...
...updated 1092 targets...
I run ./b2 -q
This will stop at your first errors, in my case:
gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.8.3/release/threading-multi/bzip2.o
libs/iostreams/src/bzip2.cpp:20:56: fatal error: bzlib.h: No such file or directory
#include "bzlib.h" // Julian Seward's "bzip.h" header.
^
compilation terminated.
"g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_DYN_LINK=1 -DBOOST_IOSTREAMS_USE_DEPRECATED -DNDEBUG -I"." -c -o "bin.v2/libs/iostreams/build/gcc-4.8.3/release/threading-multi/bzip2.o" "libs/iostreams/src/bzip2.cpp"
...failed gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.8.3/release/threading-multi/bzip2.o...
...failed updating 1 target...
Then you can install the missing dependencies, and see your second missing ones.
To see every single one of your errors, you need to install dependencies on after
another. This is good, if you are determined to make a full boost build.
In my case, I compiled bzip library http://www.bzip.org/downloads.html.
This library is tricky to make. Boost needs the dynamic version on Linux.
make -f Makefile-libbz2_so
You have to manually copy the libbz2.so.1.0.6 file to /usr/local/lib
The make two symbolic links
libbz2.so.1 -> libbz2.so.1.0.6
libbz2.so -> libbz2.so.1
After this my boost can be made and I saw:
The Boost C++ Libraries were successfully built!
Or try ./b2 -s NO_BZIP2=1 to skip
So, a little bit of more research resulted in the following.
One can get the build configuration and other build output using
b2 [options]
b2 --help reveals the options that can be used. I used the following approaches to diagnose exactly which targets were failing or getting skipped.
Approach 1
As suggested by #JanHenke in comments, I ran the same command
b2 -j4 --build-dir=build toolset=gcc --build-type=complete --stagedir=C:\SW\Boost -sNO_BZIP2=1
(as mentioned in question) again.
Result: All tragets that are already built are skipped and only failed ones are shown.
Problem: If there are many targets which failed then this just floods the console and it is difficult to find out what is going on.
Approach 2
Run the command (see 1) and select all from the command prompt using right mouse click, and then click gain to copy and paste it in a text editor so that is searchable.
Result: Usable insights can be drawn by searching for failed or error keywords
Problem: Still not the optimal way as not all the info is vailable on the current cmd window.
Approach 3
Not Done as for me 2. worked, but should surely work
Create a batchfile where in, the command is written and all that is printed on the cmd window, gets logged in a text file using the > or >> operators.
Result: Will be the best way (known to me till now) to know which exact targets are getting failed and a proper diagnostic action can be taken.
PS: I found that the there is a bug when trying to build serialization library with MinGW. Below the error I am facing and a link to boost forum which talks about the same error.
gcc.compile.c++ build\boost\bin.v2\libs\serialization\build\gcc-mingw-4.8.1\debug\xml_woarchive.o
In file included from ./boost/archive/detail/utf8_codecvt_facet.hpp:23:0,
from ./boost/archive/impl/xml_woarchive_impl.ipp:34,
from libs\serialization\src\xml_woarchive.cpp:28:
./boost/detail/utf8_codecvt_facet.hpp:116:30: error:
function 'boost::archive::detail::utf8_codecvt_facet::utf8_codecvt_facet(std::size_t)'
definition is marked dllimport
More info Reference1 and Reference2.
Sadly have not found a solution for it yet. Also, it is not the scope of this question.
TLDR: Getting fatal error 'failed to get process times' on cross-native build of gcc. Can I remove report_times code from gcc.c OR use gcc command line option to disable report_times OR build gcc without libiberty (which contains pex_get_times used by report_times
DETAIL
After beating my head against various problems I've (finally) successfully used the Android NDK standalone toolchain to build binutils 2.23 and gcc 4.70.
My current problem is getting it to run on my device.
I've written a standard 'hello world' (copied from here) to test gcc on my device. When I run:
arm-linux-eabi-gcc hello.c -o hello
or:
arm-linux-eabi-gcc hello.c
I get the following error:
arm-linux-eabi-gcc: fatal error: failed to get process times: No such file or directory.
Google did not return much except for links to gcc.c source. Examining the source, I found the error in a function (module? extension?) called report_times. The error is returned by the function (module? extension?) pex_get_times....I'm guessing it does so if it can't get the process times.
The pex_get_times function (module? extension? I'm not sure what it is) is defined in libiberty. I can use --disable-build-libiberty, but it doesn't help for the host (my NookHD) gcc build.
My question(s):
Can this portion of gcc.c be safely (and easily) removed...i.e. the report_times function and everything associated with it?
or
Is there a command line option to tell arm-linux-eabi-gcc NOT to use report_times?
or
Is there a way to disable build of libiberty for host/target for both gcc and binutils, and would that fix the error?
As always...I'll keep researching while awaiting an answer.
Found this about an hour after posting this question. Maybe two.
Apparently report_times is part of debugging symbols (?) for GCC. To exclude report_times (which causes the 'failed to get process times' from the original question) you have to build the non-debug...or release...version of gcc.
To do this, I used info from this link: http://www-gpsg.mit.edu/~simon/gcc_g77_install/build.html
BUT, I omitted the -g from the LIBCXXFLAGS and LIBCFLAGS and I added LIBCPPFLAGS without -g just in case. Ran make DESTDIR=/staging/install/path install-host, tarballed and transferred to device. No more 'failed to get process times' error.
I am seeing another error, but it is not related to this question
I'm trying to Cross compile a kernel for Android using Ubuntu.
After successfully setting up the menuconfig, and compiling with the following option:
make ARCH=arm CROSS_COMPILE="arm-bravo-" -i -j10
It starts building, but then terminates with a lot of these errors:
error: variable '*something*' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
Now I understand that this can be fixed by running gcc with --disable-werror option. Probem is that this is a huge project (kernel) and I am not well versed enough with make and Makefile, to know where I have to set this value. Kindly help me understand and fix this problem.
After weeks, I'm now in a position to answer my own question..
Look for KBUILD_CFLAGS in the main Makefile, and add the following to suppress warnings as errors:
KBUILD_CFLAGS += -w
// if all errors are to be suppressed
KBUILD_CFLAGS += -Wno-error=unused-but-set-variable
// if that specific error is to be suppressed.