My Code::Blocks (version 17.12, I think this is the latest version) has been working fine for the last couple of months, but all of a sudden it won't run my code anymore.
When I press 'Build and run', a console window pops open as expected, but from then on nothing happens. Nothing is printed in it, not even if I wait for several full minutes.
At first I thought there might be some obscure problem with my particular code, but the problem persists across all projects. Even when I simply build the default Hello World program (an unedited newly-created project), it doesn't work.
The build log is no help either. It gives no indication that anything has gone wrong and in fact shows nothing out of the ordinary (apart from me closing the window after a while).
-------------- Build: Debug in simple_test (compiler: GNU GCC Compiler)---------------
mingw32-g++.exe -Wall -fexceptions -g -std=c++14 -IC:\Users\[MY_NAME]\Documents\[PATH]\eigen-eigen-b3f3d4950030\eigen-eigen-b3f3d4950030 -c C:\Users\[MY_NAME]\Documents\[PATH]\simple_test\main.cpp -o obj\Debug\main.o
mingw32-g++.exe -o bin\Debug\simple_test.exe obj\Debug\main.o -O3
-------------- Build: Debug in simple_test (compiler: GNU GCC Compiler)---------------
mingw32-g++.exe -o bin\Debug\simple_test.exe obj\Debug\main.o -O3
Output file is bin\Debug\simple_test.exe with size 1.51 MB
Process terminated with status 0 (0 minute(s), 1 second(s))
0 error(s), 0 warning(s) (0 minute(s), 1 second(s))
-------------- Run: Debug in simple_test (compiler: GNU GCC Compiler)---------------
Checking for existence: C:\Users\[MY_NAME]\Documents\[PATH]\simple_test\bin\Debug\simple_test.exe
Executing: "C:\Program Files (x86)\CodeBlocks/cb_console_runner.exe" "C:\Users\[MY_NAME]\Documents\[PATH]\simple_test\bin\Debug\simple_test.exe" (in C:\Users\[MY_NAME]\Documents\[PATH]\simple_test\.)
Process terminated with status -1073741510 (0 minute(s), 6 second(s))
I can't begin to fathom what's caused this problem, or even what changed on my computer that could have brought this on.
Edit: I'm still on Windows 8.
Edit: even a reinstall of Code::Blocks did not fix the issue, whereas a restart of my computer did. I have no idea what happened or why, but at least it's working for now.
Related
everyone.
I'm try to build CPU2017 intrate and fprate test set on aarch64 server with gcc9.3. All the benchmark build successed, except 510.parest_r. Then i try build it with gcc9.4, meet the same error. I used the Example-gcc-linux-aarch64.cfg as configure file, just edit the gcc path.
Here is the failed info:
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/me-tomography/synthetic_data.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/me-tomography/synthetic_data.cc
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/multigrid/mg_base.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/multigrid/mg_base.cc
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/me-tomography/measurements.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/me-tomography/measurements.cc
init2.c:52: MPFR assertion failed: p >= 2 && p <= ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
during GIMPLE pass: forwprop
source/me-tomography/measurements.cc: In constructor 'METomography::Measurements::ReferencedMeasurements::RatioMinusRatio<dim, number>::RatioMinusRatio(const libparest::Slave::Stationary::ProblemDescription&, const dealii::Function<dim>&, const std::set<unsigned char>&) [with int dim = 3; number = double]':
source/me-tomography/measurements.cc:1739:7: internal compiler error: Aborted
1739 | RatioMinusRatio<dim,number>::
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
0xafbd97 crash_signal
../.././gcc/toplev.c:326
0xffff9e304d78 __GI_raise
../sysdeps/unix/sysv/linux/raise.c:51
0xffff9e2f1aab __GI_abort
/build/glibc-RIFKjK/glibc-2.31/stdlib/abort.c:79
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
specmake: *** [/home/spec/cpu2017_aarch64/benchspec/Makefile.defaults:356: source/me-tomography/measurements.o] Error 1
specmake: *** Waiting for unfinished jobs....
The failed info seem be caused by the MPRF float percision setting?
I tried build 510.parest_r with llvm-10, build success.
By the way, i build same gcc9.3 in x86_64 server, build 510.parest_r success.
You've found a bug in an older version of GCC (or possibly your system's RAM is failing, but unlikely if it consistently crashes at the same place). Or perhaps a bug in MPFR, although that seems less likely.
If you preprocess that source (add -E or -save-temps to the command line that crashed) and put it on https://godbolt.org/, does it still crash the same way with current ARM64 GCC, e.g. a nightly build of trunk? (https://godbolt.org/z/K6GnrYrj1 is ARM64 GCC trunk, with your command line args without the preprocessor stuff, which won't matter when compiling CPP output.)
If it still crashes with current GCC, then file a bug report on https://gcc.gnu.org/bugzilla/, ideally with a MCVE of the part of the source that triggers the bug. (Remove as many parts of the file as you can while preserving the crash behaviour. e.g. take out tons of stuff, undo if that makes it compile.)
If it doesn't crash with newer GCC, it might already be a known bug, or got fixed by accident, or a different MPFR or other library version mattered. In that case, maybe not worth reporting it upstream. Or if you do make sure to include the fact that the range of affected versions doesn't include GCC12 or current trunk. Probably this Stack Overflow Q&A is sufficient for future users to know that it's a known bug.
I'm trying to compile a uvm project on my machine and I keep getting the following error message. I'm on Manajaro, I have multilib enabled on my system and I have followed the instructions on this page All the required dependencies are Installed.
I can start modelsim from commandline without any issues, but when I call this makefile, it always fails at the below line. Which makes me believe I might be missing something related to gcc, but I'm not sure what that is and googling this particular issue has yielded no results.
Compiling /tmp/cyberbemon#cyberbemon-x570aorusmaster_dpi_77438/linux_gcc-5.3.0/exportwrapper.c
# ** Fatal: ** Fatal: (vsim-3828) Could not link 'vsim_auto_compile.so': cmd = '/opt/modeltech/gcc-5.3.0-linux/bin/g++ -shared -fPIC -m32 -o "/tmp/cyberbemon#cyberbemon-x570aorusmaster_dpi_77438/linux_gcc-5.3.0/vsim_auto_compile.so" /home/cyberbemon/Development/uvm/final/tb_build/sub_system_tbs/pss_tb/sim/work/_dpi/auto_compile#/linux_gcc-5.3.0/*.o "/tmp/cyberbemon#cyberbemon-x570aorusmaster_dpi_77438/linux_gcc-5.3.0/exportwrapper.o" -Wl,-Bsymbolic '
# (vsim-50) A call to system(/opt/modeltech/gcc-5.3.0-linux/bin/g++ -shared -fPIC -m32 -o "/tmp/cyberbemon#cyberbemon-x570aorusmaster_dpi_77438/linux_gcc-5.3.0/vsim_auto_compile.so" /home/cyberbemon/Development/uvm/final/tb_build/sub_system_tbs/pss_tb/sim/work/_dpi/auto_compile#/linux_gcc-5.3.0/*.o "/tmp/cyberbemon#cyberbemon-x570aorusmaster_dpi_77438/linux_gcc-5.3.0/exportwrapper.o" -Wl,-Bsymbolic >'/tmp/questatmp.AFzKOV' 2>&1) returned error code '1'.
# The logfile contains the following messages:
# /lib/crti.o: file not recognized: File format not recognized
# collect2: error: ld returned 1 exit status
This issues was caused by Modelsim using a different gcc version, manually deleting all the gcc-..*-linux folders from modelsim directory forced it to use my system GCC and that has solved the issue.
This solution was suggested here
Instead of manually deleting it, you can re-run the installer and choose to remove the GCC components. You will get the same result.
I have been using CodeBlocks with the Digital Mars D compiler and the LLVM Clang compiler for some time without any problems. Now I need to use the LDC D compiler and am having problems with the linker invocation.
I get the following output:
-------------- Build: Debug in test (compiler: LLVM D Compiler)---------------
ldc2.exe -g -I"C:\Program Files\LDC\ldc2-1.13.0-windows-x64\bin" -c hello.d -of=obj\Debug\hello.o
ldc2.exe -L-L"C:\Program Files\LDC\ldc2-1.13.0-windows-x64\lib" -of=bin\Debug\test.exe obj\Debug\hello.o
Error: unrecognized file extension o
Process terminated with status 1 (0 minute(s), 0 second(s))
0 error(s), 0 warning(s) (0 minute(s), 0 second(s))
The compile step seems to work fine, but specifying ldc2.exe as a linker clearly fails.
Similarly, using ldmd2.exe and lld-link.exe in CodeBlocks' linker specification produce similar errors.
Any suggestions?
Looks like Code::Blocks is using the .o extension for object files on Windows, while the linker driver in the compiler frontend is probably expecting object files to have the .obj extension, which is more common on Windows.
I'm not familiar with Code::Blocks or how it interfaces with D compilers, but you can try checking to see if it has a setting to control what extension is used for object files. This may be a bug (or, simply, lacking Windows support) in whatever code is responsible for building D compiler command lines in Code::Blocks.
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.