Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#50848 - [avr-gcc] Compile error with deconstructurs

Attached to Project: Community Packages
Opened by NicoHood (NicoHood) - Tuesday, 20 September 2016, 17:48 GMT
Last edited by Jakob Gruber (schuay) - Saturday, 24 September 2016, 07:23 GMT
Task Type Bug Report
Category Packages
Status Assigned
Assigned To Anatol Pomozov (anatolik)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


I am trying to package arduino with the upstream avr-gcc and it gave me some compilation errors (see link).
The bug has been described and discussed here and the cause seems to be the configuration of avr-gcc:

A comparisio between a working and a not working configuration can be found here:

It would be nice if you can give me a hint which of the configuration options might have caused the bug, then I can try to recompile avr-gcc myself and check again.
This task depends upon

Comment by Anatol Pomozov (anatolik) - Friday, 23 September 2016, 15:44 GMT
How to reproduce the issue? Do you have a simple *.c that shows the problem with current avr-gcc?
Comment by NicoHood (NicoHood) - Friday, 23 September 2016, 15:53 GMT
I currently have no simple c file, but you can reproduce this with the arduino ide.

* Install the current arduino AUR package.
* Set this line of platform.txt to /usr/bin/
* Compile a sketch and test if that works in general
* You can then try the software serial example which throws the error. It can be found in file>examples>softwareserial>softwareserialexample

To debug this issue you should also remove all flags that contain "lto" in platform.txt then you do not get the segmentation fault, but the real error instead. You also want to turn on verbose output and compiler warnings in the preferences to see which compiler is used.

I once got a working avr-gcc build with the following settings:
${srcdir}/${_basedir}/configure \
--disable-install-libiberty \
--disable-libssp \
--disable-libstdcxx-pch \
--disable-libunwind-exceptions \
--disable-linker-build-id \
--disable-nls \
--disable-werror \
--disable-__cxa_atexit \
--enable-checking=release \
--enable-clocale=gnu \
--enable-gnu-unique-object \
--enable-gold \
--enable-languages=c,c++ \
--enable-lto \
--infodir=/usr/share/info \
--libdir=/usr/lib \
--libexecdir=/usr/lib \
--mandir=/usr/share/man \
--prefix=/usr \
--target=avr \
--with-as=/usr/bin/avr-as \
--with-gnu-as \
--with-gnu-ld \
--with-ld=/usr/bin/avr-ld \ \
--with-system-zlib \

But you always need to do a clean build. Remove the whole "src" folder and then recompile. Otherwise the normal build worked for me afterwards. I also had some warnings that my package links to my src directory. I do not know why, I have not debugged this further. You should have a working avr-gcc and a not working setting now. One of the settings I left out should cause the problem. As you've possibly seen on the mailing list I am offline for a few weeks, otherwise I'd try this myself.

I hope that was enough information in the short time. If not I can debug this when I am back.
Comment by NicoHood (NicoHood) - Tuesday, 04 October 2016, 10:19 GMT
@anatolik I could solve the issue partly. Details can be found here:

I need you to rebuild the package with `--disable-__cxa_atexit` as a compile option. It would be nice if you know why this was enabled. If not we should possibly just disable it, as it causes the mentioned problem and no other distribution has it enabled as i've seen this so far.

The LTO bug is possibly an gcc 6.x problem and not the configuration. I've no idea to debug this yet, but the workaround for the cpp flags would make arduino work for now. Maybe we should report this upstream at the gcc bugtracker. But I have very few compiler compilation knowledge, so I cannot really tell whats going on.
Comment by Anatol Pomozov (anatolik) - Tuesday, 04 October 2016, 13:25 GMT
> It would be nice if you know why this was enabled.
AFAIK This flag is enabled by default.

Here is a bit more info

This is due to that the default option for _cxa_atexit has changed in gcc 4.2.1. _cxa_atexit is dependent on implementation of the _cxa_atexit function in the C-library that is used.
In GCC 4.2.x release notes it says:
"The configure variable enable-__cxa_atexit is now enabled by default for more targets. Enabling this variable is necessary in order for static destructors to be executed in the correct order, but it depends upon the presence of a non-standard C library in the target library in order to work. The variable is now enabled for more targets which are known to have suitable C libraries."
uClibc 0.9.28 does not have _cxa_atexit, but 0.9.29 does have it. Newlib has _cxa_atexit.
Solution is to explicit enable or disable _cxa_atexit when configuring gcc for the actual target and C-library.

It might be that avr-libc does not have __cxa_atexit function.

Also, what do you see if you try to compile your code using original gcc package with -fno-use-cxa-atexit option.
Comment by NicoHood (NicoHood) - Tuesday, 04 October 2016, 14:20 GMT
If I add -fno-use-cxa-atexit as cpp flag the code compiles fine (without lto). With LTO I still need the extra flag. So the compile time switch does the same as if I'd rebuild avr-gcc. Maybe the avr-libc is outdated?

Edit: also found the issue here:
Comment by Anatol Pomozov (anatolik) - Tuesday, 04 October 2016, 17:31 GMT
avr-libc uptodate but it just dot implement _cxa_atexit. I guess I need to use --disable-__cxa_atexit to avoid the issue.
Comment by NicoHood (NicoHood) - Tuesday, 04 October 2016, 17:33 GMT
But the LTO issue is still there (which is caused by disabling the cxa exit it seems). We should possibly file a bug at avr-libc?
Comment by Anatol Pomozov (anatolik) - Tuesday, 04 October 2016, 17:58 GMT
Yeah, avr-libc maillist is a great starting point for this issue discussing.
Comment by Anatol Pomozov (anatolik) - Tuesday, 04 October 2016, 19:24 GMT
avr-gcc-6.2.0-2 has been pushed to [testing]. Please check it.
Comment by NicoHood (NicoHood) - Tuesday, 04 October 2016, 19:32 GMT
Is there also a configure option for the -fno-devirtualize flag which we also could include?

The "download from mirror" link is not available here and I've not setup a vm with testing yet where arduino would built like this.
Comment by NicoHood (NicoHood) - Friday, 14 October 2016, 16:14 GMT
The new avr-gcc works as expected equal to the flag `-fno-use-cxa-atexit`. However I still need `-fno-devirtualize` which misses some optimization I think. I've reported this at the avr-libc mailing list, but joerg also has no idea how to fix it. He would add a missing cxa_exit() if someone tells him how to. I think the best idea is to file a bug at gcc?

What I'd like is to enable it again, but fix the issue we have with LTO.
Comment by Anatol Pomozov (anatolik) - Wednesday, 08 July 2020, 05:47 GMT
Hi folks, what is the current state of this issue?
Comment by NicoHood (NicoHood) - Saturday, 11 July 2020, 08:09 GMT
That is a good question, its been a long time now. I've tried to investigate again:

"--disable-__cxa_atexit" Seems to solve the first part of the issue.
`-fno-devirtualize` seems to be not required anymore. Any problematic code is compiling now without the patch. I do not exactly know why it works now, but I will remove the patch from the avr-core and we can close this issue.