Hi Hakan, pointing to this issue in a developer discussion and also this link (https://savannah.nongnu.org/forum/forum.php?forum_id=8460 <https://savannah.nongnu.org/forum/forum.php?forum_id=8460>) led to the maintainer Jörg Wunsch. It looks like as if he could be one of the key persons to address regarding this issue, as the key-package avr-libc has a dependency on gcc-avr which determines device compatibility. The obviously current state of device support for avr-libc 2.0.0 as part of the latest AVR-toolchain 3.6.1 by Microchip can be found here: https://www.microchip.com/webdoc/AVRLibcReferenceManual/index_1supp_devices.html <https://www.microchip.com/webdoc/AVRLibcReferenceManual/index_1supp_devices.html>. Would that mean that a new version of avr-libc with full compatibility to gcc 8.3 (for example) could ease portability of the complete toolchain, while preserving device support at the same time?
Another info I came across is that the distribution Arch Linux maintains a very recent version of the toolchain (https://archlinux.pkgs.org/rolling/archlinux-community-x86_64/avr-gcc-9.1.0-1-x86_64.pkg.tar.xz.html <https://archlinux.pkgs.org/rolling/archlinux-community-x86_64/avr-gcc-9.1.0-1-x86_64.pkg.tar.xz.html>). Would it be possible to port these sources to the Debian? How did the maintainers at Arch manage to achieve compatibility with the latest gcc-mainline? According to the package content this is even based on avr-libc 2.0.0. Do they have limitations regarding device support? Nightwalker-87 > Am 25.07.2019 um 18:41 schrieb nightwalker...@t-online.de: > > Dear Hakan, > > Thank You very much for your quick reply. > > Unfortunately I don’t know too much about the development history of this > package @Debian and the related decisions. > It would be helpful though to have other developers and maintainers to have > their say on this to help find a common solution. > At first one should find out if support for newer devices would suffer from > such an approach. I have not come across that topic yet... > > Best regards > Nightwalker-87 > >> Am 25.07.2019 um 18:17 schrieb Hakan Ardo <hakan.a...@gmail.com >> <mailto:hakan.a...@gmail.com>>: >> >> Hi, >> gcc-avr was originally built from the mainline gcc, but was later split out >> by to build depend on gcc-source as it was not wanted in the mainstream gcc >> package. Has that situation changed? >> >> It was then decided to base the package on the Atmel distribution instead of >> the upstream source as that gave support for newer devices faster. >> >> Now, as far as I can tell, Atmel have dropped their source distribution and >> only provided binaries. So something have to be done indeed. >> >> Switching back to use upstream source would be one option. But will that >> mean we'll have to dropp support for newer devices? >> >> Den tors 25 juli 2019 17:27nightwalker-87 <nightwalker...@t-online.de >> <mailto:nightwalker...@t-online.de>> skrev: >> Package: gcc-avr >> Version: 1:5.4.0+Atmel3.6.1-2 >> Severity: normal >> Tags: newcomer >> >> Dear Maintainer, >> >> It appears that the gcc-avr toolchain in the debian repository is severely >> outdated compared to the current level of version support for the main gcc >> toolchain. This leaves avr-developers wishing to use newer C language >> features >> behind and makes it necessary to use external toolchains (source based or >> pre- >> compiled). Pointing to this in the debian-devel IRC-Channel, lead to the >> following idea: "if it was in mainline, the gcc-avr package could be dropped >> in >> favour of a package built from the mainline version of gcc." as well as "an >> example of such a source package is gcc-arm-none-eabi, the equivalent for avr >> could be added by someone interested, then gcc-avr could be removed." (user: >> pabs) From my point of view this could be a promising approach to resume >> development on this topic. I would appreciate, if debian developers could >> take >> action on this topic to resolve this long lasting backlog and make >> contribution >> to make debian even more attractive for development. As it stands the avr-8 >> architecture will remain for many years to come in some parts even with new >> applications. >> >> >> >> -- System Information: >> Debian Release: bullseye/sid >> APT prefers testing >> APT policy: (500, 'testing'), (500, 'stable') >> Architecture: amd64 (x86_64) >> >> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) >> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE >> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), >> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) >> Shell: /bin/sh linked to /bin/dash >> Init: systemd (via /run/systemd/system) >> LSM: AppArmor: enabled >> >> Versions of packages gcc-avr depends on: >> ii binutils-avr 2.26.20160125+Atmel3.6.1-4 >> ii libc6 2.28-10 >> ii libgcc1 1:8.3.0-7 >> ii libgmp10 2:6.1.2+dfsg-4 >> ii libmpc3 1.1.0-1 >> ii libmpfr6 4.0.2-1 >> ii libstdc++6 8.3.0-7 >> ii zlib1g 1:1.2.11.dfsg-1 >> >> gcc-avr recommends no packages. >> >> Versions of packages gcc-avr suggests: >> ii avr-libc 1:2.0.0+Atmel3.6.1-2 >> ii gcc 4:8.3.0-1 >> pn gcc-doc <none> >> >> -- no debconf information >
