I have an RTOS project using C++ without exception support (-fno-exceptions). I'm trying to use -Og, but I find it gives me:
undefined reference to `std::terminate()'
This corresponds to exception handling.
The problem doesn't occur with the other -O options.
gcc is gcc-arm-none-eabi-7-2018-q2-update
Does -Og require exception handling for some reason?
Update
The trigger for this error can be the noexcept keyword.
It's an interesting conflict. Code is trying to say that it wants to use std::terminate() instead of try/except for its exceptions. Meanwhile, with -fno-exceptions, it isn't possible to throw an exception, because the throw will be a compile time error. So that might lead someone to think noexcept is ignored if -fno-exceptions is specified.
In my project which has no 'throw' statement at all, somehow there are particular points of seemingly innocent code that result in the compile error. Removing noexcept at the erroring locations causes the project to build and run properly.
If I make a small project I can't yet reproduce it.
Related
For various reasons the code i'm working with is compiled using the -fno-exceptions option in MingW GCC 11.2. In certain places i'd like to make use of the parallel algorithms from C++17. However, when attempting to use those algorithms with policy set to std::execution::par, i get errors trying to compile: error: exception handling disabled, use '-fexceptions' to enable because of catch (const std::bad_alloc&) from utils.h.
Am i doomed to not being able to use those algorithms unless i enable exceptions?
I am a Windows developer with some knowledge of C++ EH and SEH implementation in VC++ but new to MinGW. I have built an open source application on MinGW where a dll throws a C++ exception and a client .exe catches it with two catch clauses. One catch clause is "catch (std::exception &e)" and the subsequent one is "catch(...)".
My application terminates with a call to abort despite the latter catch handler.
From searching the web, I understand that gcc exception handling uses pointer comparison to determine whether that type of a thrown exception matches a catch clause. Which can cause problems if the RTTI type descriptor instance used in the throwing and the catching modules differ. In VC++ a catch handler with ellipsis type ("catch (...)") does not do any type matching. However, for my mingw application the ellipsis catch is not determined as handling the thrown exception. I tried to set a breakpoint on ___gxx_personality_v0 to debug this but gdb says that symbol is undefined even though "nm executable.exe" built with debugging shows the symbol as defined.
Any ideas about how "catch (...)" is handled by the personality routine ? Any pointers on how to debug and/or fix this would be appreciated. I really would like the app to terminate cleanly without a popup saying "The application has requested to be terminated in an unusual way".
Thanks for any help,
--Patrick
Update: I found the solution in another post here about the same issue: Exceptions are not caught in GCC program . It turns out that both the dll and the executable were built with "-static-libgcc". Changing that to "-shared-libgcc" fixed the issue.
The quote from the gcc manual from the above post:
... if a library or main executable is supposed to throw or catch exceptions, you must link it using the G++ or GCJ driver, as appropriate for the languages used in the program, or using the option -shared-libgcc, such that it is linked with the shared libgcc.
I'm on Ubuntu 13.04 32 platform. I'm trying to compile awn with latest vala. I get following error message.
vala-utils.cc: In function 'void awn::vala_array_destroy(gpointer, gint, GDestroyNotify)':
vala-utils.cc:358:6: error: no previous declaration for 'void awn::vala_array_destroy(gpointer, gint, GDestroyNotify)' [-Werror=missing-declarations]
cc1plus: some warnings being treated as errors
How can I fix that error?
At the top of vala-utils.cc insert the function prototype:
void vala_array_destroy(gpointer array, gint array_length, GDestroyNotify destroy_func);
This will silence the warning which is causing the build to fail due to -Werror defined in the Makefile. Consider raising a pull request for the benefit of the maintainers.
Alternatively modify ln.89 in configure.ac and remove the -Werror to stop the warning failing the build.
This actually a warning, and a rather pedantic one at that.
It's saying that the global function awn::vala_array_destroy has not been declared beforehand. Usually this is a sign of a programmer's mistake, but from the source it seems to me that:
this function is only supposed to be used by awn::vala_array_free directly below it (in which case it should really have been given internal linkage), or
a declaration is available in some header elsewhere (in which case it's probably in the wrong header, as it ought to be in vala-utils.h).
The long and short of it is that the code is probably fine, if a little strangely designed. This case is being treated as an error because you have -Werror turned on for this warning, turning it into an error.
I don't know how you're building the library, but you could adjust the compiler flags to avoid this; by default, GCC does not emit this warning, nor turn it into an error. Alternatively, you could add the function declaration into vala-utils.h yourself. You should also take up the issue with the library's maintainers.
Update: I found the culprit on line 89 of AWN's configure.ac. You should definitely take this up with the library maintainers. I'd be amazed if this had not already been reported as a bug; I believe it was introduced in this revision.
I am writing a firmware for an ARM microcontroller. I have built the cross-compiler without syscalls, actually my RTOS (ChibiOS) provides a simple syscalls implementation.
All my code is written in C excepting some parts where I only use C++ for linking with Eigen library (a C++ template library for linear algebra, it is only headers).
If I compile my source example code with -O2 -DNDEBUG (as far as I know with NDEBUG the code won't need assert()) everything compiles fine and the firmware works.
If I compile my source example code with -O0 I have the following:
Linking build/ch.elf
/home/noether/workspace/tool-chains/arm-none-eabi-4.6.2/lib/gcc/arm-none-eabi/4.6.2 /../../../../arm-none-eabi/lib/thumb/cortex-m4/libc.a(lib_a-abort.o): In function `abort':
/home/noether/workspace/tool-chains/summon-arm-toolchain/build/arm-none-eabi/thumb /cortex-m4/newlib/libc/stdlib/../../../../../../../gcc-4.6.2/newlib/libc/stdlib /abort.c:63: undefined reference to `_exit'
/home/noether/workspace/tool-chains/arm-none-eabi-4.6.2/lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/thumb/cortex-m4/libc.a(lib_a-signalr.o): In function `_kill_r':
/home/noether/workspace/tool-chains/summon-arm-toolchain/build/arm-none-eabi/thumb/cortex-m4/newlib/libc/reent/../../../../../../../gcc-4.6.2/newlib/libc/reent/signalr.c:61: undefined reference to `_kill'
/home/noether/workspace/tool-chains/arm-none-eabi-4.6.2/lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/thumb/cortex-m4/libc.a(lib_a-signalr.o): In function `_getpid_r':
/home/noether/workspace/tool-chains/summon-arm-toolchain/build/arm-none-eabi/thumb/cortex-m4/newlib/libc/reent/../../../../../../../gcc-4.6.2/newlib/libc/reent/signalr.c:96: undefined reference to `_getpid'
collect2: ld returned 1 exit status
make: *** [build/ch.elf] Error 1
It does not matter if I put -DNDEBUG, I have the same output.
I am using those flags as well, -fno-exceptions and fno-rtti.
If I do not use/link the Eigen library (the only C++ stuff), g++ compiles the source fine even with -O0.
Actually, I implemented a simple _kill _getpid and _exit functions, and the code compiles, but the code goes from 13KB to 130KB, and It crashes (maybe I haven't written well those functions).
What I want is to remove this stuff from my code (abort, etc) if I use -O0, as it is done (I guess) with -O2.
Thank you very much. Let me know if you need more information.
These references are almost certainly due to using assert(); that will call abort() on failure, which in turn will try to raise a signal (using the kill() syscall in this implementation) to abort the process. Obviously, this isn't possible if you can't make syscalls.
Building with -DNDEBUG (like you do in the optimised version) will fix this; it causes the assert() macro to generate no code, so there will be no references to abort(). The optimisation level itself shouldn't make any difference.
Alternatively, if you want to preserve your assertions, you could implement your own assert() macro that doesn't require any syscalls.
You could simply implement stubs for those missing syscalls and link them to your code. That will keep the linker quiet, but you might make the stubs do something sensible or useful. exit() might disable interrupts and loop indefinitely or force a reset. _kill() might hook into your RTOS to terminate a thread, or simply call _exit(), and _getpid() might return some dummy value or an RTOS thread ID.
After switching default compiler in qt to gcc 4.6.2 I'm getting following error:
c:\ndk_buildrepos\qt-desktop\src\winmain\qtmain_win.cpp:93: error: undefined reference to `_Unwind_Resume'
With the compiler switch I also did two more things - I overwrote mingw32make with make from gcc 4.6.2. I did the same for the clean step.
Is there a way to fix it?
_unwind_resume is part of the compiler runtime library - it deals with unwinding the stack when handling an exception.
This post http://www.linuxquestions.org/questions/linux-newbie-8/undefined-symbol-_unwind_resume-192813/ suggests linking with the library gcc_s ( -lgcc_s )
Here's a similar solution: http://www.pgroup.com/userforum/viewtopic.php?t=1636&sid=a1f1e9e649686d97a21ba367284ea3ce
Here's someone with the same problem using QT: http://www.qtcentre.org/threads/33394-Link-errors-undefined-reference-to-_Unwind_Resume-and-__gxx_personality_v0 . They say "Running C:\Qt\2010.04\bin\qtenv.bat fixes the problem."