Recently upgraded my main machine from Lucid Lynx (10.04 LTS... yes, ancient!) to Bionic Beaver (yes, it's a silly name... let's get over it quickly... ;-)
I seem to have an issue now when using any of the Atmel toolchains to build my projects:
2 joeymorin@stinky:~/c.src/AVR/blink_delay_ms$ make avr-gcc -DF_CPU=16000000UL -I . -include blink_delay_ms.h -Os -mmcu=attiny85 -mrelax -fjump-tables -maccumulate-args -fno-inline-small-functions -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -fno-tree-scev-cprop -fsplit-wide-types -mbranch-cost=3 -pedantic -H -Wc++-compat -mstrict-X -std=gnu11 -g -W -Wall -Wextra -Wunused -Wstrict-prototypes -Wundef -Werror -fno-exceptions -fdata-sections -ffunction-sections -save-temps -c -include fuses_and_lockbits.h blink_delay_ms.c . /home/joeymorin/Software/AVR_toolchain/avr8-gnu-toolchain-linux_x86_220.127.116.11/avr/include/util/delay.h .. /home/joeymorin/Software/AVR_toolchain/avr8-gnu-toolchain-linux_x86_18.104.22.168/avr/include/util/delay_basic.h .. /home/joeymorin/Software/AVR_toolchain/avr8-gnu-toolchain-linux_x86_22.214.171.124/avr/include/math.h Multiple include guards may be useful for: ./blink_delay_ms.h ./fuses_and_lockbits.h as: loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME))' failed. avr-gcc: internal compiler error: Aborted (program as) Please submit a full bug report, with preprocessed source if appropriate. See <http://www.atmel.com> for instructions. Makefile:174: recipe for target 'blink_delay_ms' failed make: *** [blink_delay_ms] Error 4
This seems to be related to:
(use CTRL-F to find loadlocale)
Bertie 2018-05-16 13:57:51 UTC #316
I have a problem with the new glibc:
Programs from the avr-toolchain, such as avr-gcc, as, etc. exit with an error:as: loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME))' failed.
Although my locale is correct, the variable LC_TIME does not seem to be imported correctly by glibc for my specific setting.
The temporary solution is:$ export LANG=C
in the current terminal session before running an affected program. (This will then be set for the duration of the terminal session) , or$ LANG=C program (for example $ LANG=C avr-gcc)
on a per program instance.
In 2015 I had a similar problem with glibc which affected the variable LC_COLLATE, with the same temporary solution. Seemed that only Arch based distros were affected. This remained for many months until it finally disappeared (fixed).
If you have this similar problem, do not try to downgrade glibc.
The solution proposed seems to do the trick, but I'm unclear on any side effects it may have. In particular, what might be the implications of changing the value of LANG from it's default (en_CA.UTF-8 in my case) to 'C'?