Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain
Hi, Microchip has updated it's official AVR-toolchain in May 2022 as well and provided related technical details. https://www.microchip.com/en-us/tools-resources/develop/microchip-studio/gcc-compilers Please (at least) port this version into the debian package sources ASAP. Debian seems to have lost track with recent developments for this architecture, resulting in lacking support for newer devices. This is deeply disappointing to see. Nightwalker-87
Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain
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 > <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 > <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_C
Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain
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 : > > 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 <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++68.3.0-7 > ii zlib1g1: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 > > -- no debconf information
Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain
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++68.3.0-7 ii zlib1g1: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 -- no debconf information
