[opensuse-packaging] CrossToolchain question
Hi, In CrossToolchain:avr, I see avr-gcc-* and cross-avr-gcc. What is the difference? What is correct naming? (I suppose the last one). What guidelines/rules should I follow to create CrossToolchain subproject for yet unsupported arch? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mar 23, 13 21:00:54 +0400, Matwey V. Kornilov wrote:
Hi,
In CrossToolchain:avr, I see avr-gcc-* and cross-avr-gcc. What is the difference? What is correct naming? (I suppose the last one).
The original compiler package that I bootstrapped there was cross-avr-gcc version 4.3.3 but newer compilers come from the package avr-gcc-master and are named avr-gcc-436, avr-gcc-453, avr-gcc-462, avr-gcc-47-20111105 - I have not deleted the old one, as there are rumors, that this is the one that optimizes best for 8bit CPUs. Not sure if this is still relevant.
What guidelines/rules should I follow to create CrossToolchain subproject for yet unsupported arch?
New avr target archs, or new host archs? cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 say #263A!__/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Jeff Hawn, J.Guild, F.Imendoerffer, HRB 16746 (AG Nuernberg), Maxfeldstrasse 5, 90409 Nuernberg, Germany SuSE. Supporting Linux since 1992. ☺ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Juergen Weigert wrote:
What guidelines/rules should I follow to create CrossToolchain subproject for yet unsupported arch?
New avr target archs, or new host archs?
I was afraid, I needed packages for avr32 toolchain. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mar 25, 13 22:46:41 +0400, Matwey V. Kornilov wrote:
Juergen Weigert wrote:
What guidelines/rules should I follow to create CrossToolchain subproject for yet unsupported arch?
New avr target archs, or new host archs?
I was afraid, I needed packages for avr32 toolchain.
I'd suggest to create a fresh project CrossToolchain:avr32 for this. The namespace CrossToolchain:avr implies 8bit only. avr32 is a different beast, and should not hide in a subproject of 8bitters. cheers, JW. -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 say #263A!__/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Jeff Hawn, J.Guild, F.Imendoerffer, HRB 16746 (AG Nuernberg), Maxfeldstrasse 5, 90409 Nuernberg, Germany SuSE. Supporting Linux since 1992. ☺ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
2013/3/25 Juergen Weigert <jw@suse.de>:
I'd suggest to create a fresh project CrossToolchain:avr32 for this. The namespace CrossToolchain:avr implies 8bit only. avr32 is a different beast, and should not hide in a subproject of 8bitters.
Yep, I agree. I looked into avr in seeking for examples :) -- With best regards, Matwey V. Kornilov http://0x2207.blogspot.com xmpp:0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
25.03.2013 22:39, Juergen Weigert пишет:
On Mar 23, 13 21:00:54 +0400, Matwey V. Kornilov wrote:
Hi,
In CrossToolchain:avr, I see avr-gcc-* and cross-avr-gcc. What is the difference? What is correct naming? (I suppose the last one).
The original compiler package that I bootstrapped there was cross-avr-gcc version 4.3.3 but newer compilers come from the package avr-gcc-master and are named avr-gcc-436, avr-gcc-453, avr-gcc-462, avr-gcc-47-20111105 -
Why we just don't have cross-avr-gcc48.spec in devel:gcc gcc48 like every other arch does? It is interesting that Factory supplies cross-avr-binutils but not cross-avr-gcc. May I try to push avr-support to devel:gcc? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Sat 19 Oct 2013 09:06:48 NZDT +1300, Matwey V. Kornilov wrote:
Why we just don't have cross-avr-gcc48.spec in devel:gcc gcc48 like every other arch does? It is interesting that Factory supplies cross-avr-binutils but not cross-avr-gcc. May I try to push avr-support to devel:gcc?
Let's discuss the issues to be solved a bit more first. I did a LOT of work creating oS packages, because the default AVR compiler is antiquated and newer gcc offer much better optimisations and the introduction of LTO, and I wanted to play with that. Of course newer gcc may have different bugs that could upset the Arduino community expectations so installing multiple gcc versions is required. The existing spec files needed improving in many areas and I am quite particular that this work is kept for any merge with mainline gcc: * Having multiple avr-gcc versions installed and ready to run is non-negotiable. One expects the default version to be in PATH as avr-gcc. I have put all into PATH as avr-gcc-xyz, and provided a script run-avr-gcc-xyz that puts this version into PATH first, so run-avr-gcc-xyz avr-gcc -v gives the selected version. (This is needed, unless you want to be editing makefiles, the arduino IDE and everything else in use each time you want to try a different version.) * /opt is been obsoleted some time ago. Use /usr. * The "cross-" package name prefix has no useful purpose. In fact I find it a PITA. Traditions may be all well, but I strictly stop where they give me nothing and only waste my time. The host package is called "gcc", "avr-gcc" already says everything that needs to be said. (Anyone needing another "cross-" in front of that shouldn't be running that sort of software... ;-) ) * Wrapper scripts for each of the avr-gcc etc for adjusting paths are mind-bogglingly broken. This emergency quick fix can be axed. https://bugzilla.novell.com/show_bug.cgi?id=767294 * Contrary to popular belief, building avr-gcc does NOT require avr-libc! Please fix build dependencies. Otherwise, how are you going to build avr-libc when you don't have a compiler to build it with? (Sure there are ways, but why not use the easy one.) I have put the spec files and additional source files here (read the comments): http://volker.top.geek.nz/arduino/tools/suse12.3/ The spec file is appropriately commented, please keep the comments, they are there for a reason and building cross compilers has many pitfalls. The avr-binutils are already in the OSS repo and derived from single-source. Good. Please work on its maintainer to drop the "cross-" prefix. I assume this is because the cross-compiler issue arose because of a need to build oS for ARM. avr-gcc is not in OSS, perhaps it's on someone's TODO but not there yet. Issues for AVR users/maintainers for moving binutils and gcc in with the host packages: * Less maintenance work overall, no duplicated efforts. * How does the multi-version requirement integrate? * AVR users may require changes more frequently. Is this going to become more difficult because host-gcc maintainers rightfully keep close control over changes potentially affecting openSUSE x86? * Does merging with host-gcc put pressure on AVR users regarding choice of gcc version? Choice of binutils version? Patches to avr-binutils, avr-gcc? It has been necessary in the past to patch bugs in avr-binutils that prevented use of some optimisations by gcc. AVR users need to retain this ability. There have been many patches to avr-gcc as well, most required. The suggestion by avr-gcc developers always is to upgrade gcc, but there are issues of tool-environment stability against that. Arduino still uses stone-age by default - this is common with embedded systems where investments in tool evaluation are high and essential. * Does this merge make it more difficult to make newer gcc releases for AVR available for evaluation? I am all for leveraging the work already done by host-gcc maintainers. Can it be done with the extra requirements outlined above? Sorry for not chipping in earlier, I was not subscribed. Also my replies will probably be overnight because I am in time zone UTC+13. Greetings, Volker -- Volker Kuhlmann http://volker.dnsalias.net/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 24 Oct 2013, Volker Kuhlmann wrote:
On Sat 19 Oct 2013 09:06:48 NZDT +1300, Matwey V. Kornilov wrote:
Why we just don't have cross-avr-gcc48.spec in devel:gcc gcc48 like every other arch does? It is interesting that Factory supplies cross-avr-binutils but not cross-avr-gcc. May I try to push avr-support to devel:gcc?
Let's discuss the issues to be solved a bit more first. I did a LOT of work creating oS packages, because the default AVR compiler is antiquated and newer gcc offer much better optimisations and the introduction of LTO, and I wanted to play with that. Of course newer gcc may have different bugs that could upset the Arduino community expectations so installing multiple gcc versions is required.
The existing spec files needed improving in many areas and I am quite particular that this work is kept for any merge with mainline gcc:
* Having multiple avr-gcc versions installed and ready to run is non-negotiable. One expects the default version to be in PATH as avr-gcc. I have put all into PATH as avr-gcc-xyz, and provided a script run-avr-gcc-xyz that puts this version into PATH first, so run-avr-gcc-xyz avr-gcc -v gives the selected version. (This is needed, unless you want to be editing makefiles, the arduino IDE and everything else in use each time you want to try a different version.)
We do that for non-cross GCC packages already by suffixing binaries with -4.8 for example. So you'd have avr-gcc-4.8 for example. Not sure if --program-suffix works for cross compiler builds, it's currently disabled in our spec file though (that isn't a requirement though).
* /opt is been obsoleted some time ago. Use /usr.
* The "cross-" package name prefix has no useful purpose. In fact I find it a PITA. Traditions may be all well, but I strictly stop where they give me nothing and only waste my time. The host package is called "gcc", "avr-gcc" already says everything that needs to be said. (Anyone needing another "cross-" in front of that shouldn't be running that sort of software... ;-) )
As you like ... but best done per target. Requires cross-communication with binutils (and changes there) to get BuildRequires correct.
* Wrapper scripts for each of the avr-gcc etc for adjusting paths are mind-bogglingly broken. This emergency quick fix can be axed. https://bugzilla.novell.com/show_bug.cgi?id=767294
* Contrary to popular belief, building avr-gcc does NOT require avr-libc! Please fix build dependencies. Otherwise, how are you going to build avr-libc when you don't have a compiler to build it with? (Sure there are ways, but why not use the easy one.)
Well, whatever is "required" - you can surely build a avr-elf freestanding compiler. Not sure if there are any optional features enabled for GCC when building against avr-libc.
I have put the spec files and additional source files here (read the comments): http://volker.top.geek.nz/arduino/tools/suse12.3/ The spec file is appropriately commented, please keep the comments, they are there for a reason and building cross compilers has many pitfalls.
The avr-binutils are already in the OSS repo and derived from single-source. Good. Please work on its maintainer to drop the "cross-" prefix. I assume this is because the cross-compiler issue arose because of a need to build oS for ARM. avr-gcc is not in OSS, perhaps it's on someone's TODO but not there yet.
Issues for AVR users/maintainers for moving binutils and gcc in with the host packages:
* Less maintenance work overall, no duplicated efforts.
* How does the multi-version requirement integrate?
* AVR users may require changes more frequently. Is this going to become more difficult because host-gcc maintainers rightfully keep close control over changes potentially affecting openSUSE x86?
* Does merging with host-gcc put pressure on AVR users regarding choice of gcc version? Choice of binutils version? Patches to avr-binutils, avr-gcc? It has been necessary in the past to patch bugs in avr-binutils that prevented use of some optimisations by gcc. AVR users need to retain this ability. There have been many patches to avr-gcc as well, most required. The suggestion by avr-gcc developers always is to upgrade gcc, but there are issues of tool-environment stability against that. Arduino still uses stone-age by default - this is common with embedded systems where investments in tool evaluation are high and essential.
* Does this merge make it more difficult to make newer gcc releases for AVR available for evaluation?
I am all for leveraging the work already done by host-gcc maintainers. Can it be done with the extra requirements outlined above?
Most of it is not difficult, it just needs somebody do 1) do it, 2) test it. I can help with 1) if you tell me what avr build-requires (in addition to avr-binutils) and what extra configure arguments you need (compared to the "stock" cross-compiler flags we use in the host gcc package). For 2) I rely on others. Richard. -- Richard Biener <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Oct 24, 13 10:56:55 +0200, Richard Biener wrote:
I am all for leveraging the work already done by host-gcc maintainers. Can it be done with the extra requirements outlined above?
Most of it is not difficult, it just needs somebody do 1) do it, 2) test it. I can help with 1) if you tell me what avr build-requires (in addition to avr-binutils) and what extra configure arguments you need (compared to the "stock" cross-compiler flags we use in the host gcc package). For 2) I rely on others.
I can help with 2) - my special interest is the 2k code size for ATtiny2313. - building avr-example against a range of compilers. - Or anything else you throw me. cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 say #263A!__/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Jeff Hawn, J.Guild, F.Imendoerffer, HRB 16746 (AG Nuernberg), Maxfeldstrasse 5, 90409 Nuernberg, Germany SuSE. Supporting Linux since 1992. ☺ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
25.03.2013 22:39, Juergen Weigert пишет:
On Mar 23, 13 21:00:54 +0400, Matwey V. Kornilov wrote:
Hi,
In CrossToolchain:avr, I see avr-gcc-* and cross-avr-gcc. What is the difference? What is correct naming? (I suppose the last one).
The original compiler package that I bootstrapped there was cross-avr-gcc version 4.3.3 but newer compilers come from the package avr-gcc-master and are named avr-gcc-436, avr-gcc-453, avr-gcc-462, avr-gcc-47-20111105 -
Why we just don't have cross-avr-gcc48.spec in devel:gcc gcc48 like every other arch does? It is interesting that Factory supplies cross-avr-binutils but not cross-avr-gcc. May I try to push avr-support to devel:gcc? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Oct 19, 13 00:07:01 +0400, Matwey V. Kornilov wrote:
Hi,
In CrossToolchain:avr, I see avr-gcc-* and cross-avr-gcc. What is the difference? What is correct naming? (I suppose the last one).
We wanted to get rid of the 'cross-' prefix at some point. I personally do not care so much about naming, and did not check if this move was ever completed. Probably not.
The original compiler package that I bootstrapped there was cross-avr-gcc version 4.3.3 but newer compilers come from the package avr-gcc-master and are named avr-gcc-436, avr-gcc-453, avr-gcc-462, avr-gcc-47-20111105 -
Why we just don't have cross-avr-gcc48.spec in devel:gcc gcc48 like every other arch does? It is interesting that Factory supplies cross-avr-binutils but not cross-avr-gcc. May I try to push avr-support to devel:gcc?
I once pulled all the cross-avr toolchain from Factory as it was quite broken. (cross-avr-binutils somehow survived in Factory). We then created several packages in CrossToolchain:avr, but none of them got ever submitted to Factory. Devel:gcc would make a lot of sense, if we go with mainstream gcc. Several years back, I had issues with miscompiled switch statements code size increasements. I'd recommend to double checks these again with gcc-4.8 -- it is definitly worth a try withing devel:gcc cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 say #263A!__/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Jeff Hawn, J.Guild, F.Imendoerffer, HRB 16746 (AG Nuernberg), Maxfeldstrasse 5, 90409 Nuernberg, Germany SuSE. Supporting Linux since 1992. ☺ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, 21 Oct 2013, Juergen Weigert wrote:
On Oct 19, 13 00:07:01 +0400, Matwey V. Kornilov wrote:
Hi,
In CrossToolchain:avr, I see avr-gcc-* and cross-avr-gcc. What is the difference? What is correct naming? (I suppose the last one).
We wanted to get rid of the 'cross-' prefix at some point. I personally do not care so much about naming, and did not check if this move was ever completed. Probably not.
The original compiler package that I bootstrapped there was cross-avr-gcc version 4.3.3 but newer compilers come from the package avr-gcc-master and are named avr-gcc-436, avr-gcc-453, avr-gcc-462, avr-gcc-47-20111105 -
Why we just don't have cross-avr-gcc48.spec in devel:gcc gcc48 like every other arch does? It is interesting that Factory supplies cross-avr-binutils but not cross-avr-gcc. May I try to push avr-support to devel:gcc?
I once pulled all the cross-avr toolchain from Factory as it was quite broken. (cross-avr-binutils somehow survived in Factory).
We then created several packages in CrossToolchain:avr, but none of them got ever submitted to Factory. Devel:gcc would make a lot of sense, if we go with mainstream gcc. Several years back, I had issues with miscompiled switch statements code size increasements. I'd recommend to double checks these again with gcc-4.8 -- it is definitly worth a try withing devel:gcc
Note that I ripped out the non-suse-glibc target support during hackweek as it was unused (I mainly wanted to consolidate the various .spec.in files we have - now down to two). So you have to hack this back in in a clean way. Richard. -- Richard Biener <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
2013/10/21 Richard Biener <rguenther@suse.de>:
Note that I ripped out the non-suse-glibc target support during hackweek as it was unused (I mainly wanted to consolidate the various .spec.in files we have - now down to two). So you have to hack this back in in a clean way.
What way is clean enough? Would it be better to try to specify KERNEL-OS part of the triplet directly? If we introduce %define gcc_target_os then we are able to clearly implement different behaviors for different OS-es (glibc, uClibs, newlib, none) in gcc.spec.in And I would not say that AVR is unused, look at popular Ardurino project for instance. -- With best regards, Matwey V. Kornilov http://0x2207.blogspot.com xmpp:0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, 21 Oct 2013, Matwey V. Kornilov wrote:
2013/10/21 Richard Biener <rguenther@suse.de>:
Note that I ripped out the non-suse-glibc target support during hackweek as it was unused (I mainly wanted to consolidate the various .spec.in files we have - now down to two). So you have to hack this back in in a clean way.
What way is clean enough? Would it be better to try to specify KERNEL-OS part of the triplet directly? If we introduce %define gcc_target_os then we are able to clearly implement different behaviors for different OS-es (glibc, uClibs, newlib, none) in gcc.spec.in
Have a %define for the desired libc (you have to adjust the BuildRequires after all).
And I would not say that AVR is unused, look at popular Ardurino project for instance.
Unused in the GCC package, AVR support was moved to a separate package at some point in time. Richard. -- Richard Biener <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Oct 23, 13 10:55:20 +0200, Richard Biener wrote:
Unused in the GCC package, AVR support was moved to a separate package at some point in time.
I did that move when an old compiler was the better choice. Should we go back into the main GCC package if we find that now a current GCC is a good choice? (Chances are high that 4.8 is an excellent avr compiler, I am told...) cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 say #263A!__/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Jeff Hawn, J.Guild, F.Imendoerffer, HRB 16746 (AG Nuernberg), Maxfeldstrasse 5, 90409 Nuernberg, Germany SuSE. Supporting Linux since 1992. ☺ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, 23 Oct 2013, Juergen Weigert wrote:
On Oct 23, 13 10:55:20 +0200, Richard Biener wrote:
Unused in the GCC package, AVR support was moved to a separate package at some point in time.
I did that move when an old compiler was the better choice. Should we go back into the main GCC package if we find that now a current GCC is a good choice? (Chances are high that 4.8 is an excellent avr compiler, I am told...)
;) I'm fine with moving it back in. Richard. -- Richard Biener <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
2013/10/23 Richard Biener <rguenther@suse.de>:
On Wed, 23 Oct 2013, Juergen Weigert wrote:
On Oct 23, 13 10:55:20 +0200, Richard Biener wrote:
Unused in the GCC package, AVR support was moved to a separate package at some point in time.
I did that move when an old compiler was the better choice. Should we go back into the main GCC package if we find that now a current GCC is a good choice? (Chances are high that 4.8 is an excellent avr compiler, I am told...)
Seems, I am able to compile devel:gcc/gcc48 for avr with minimal changes, but some cleanups are still required. As for me, regarding gcc version, if something works poorly it should be reported to upstream maintainers instead of sitting on old out-dated version. -- With best regards, Matwey V. Kornilov http://0x2207.blogspot.com xmpp:0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu 24 Oct 2013 05:27:56 NZDT +1300, Matwey V. Kornilov wrote:
On Oct 23, 13 10:55:20 +0200, Richard Biener wrote: I did that move when an old compiler was the better choice. Should we go back into the main GCC package if we find that now a current GCC is a good choice? (Chances are high that 4.8 is an excellent avr compiler, I am told...)
4.8 may be the best choice at this point in time, however then things move and the version best for host may not be the same that is best for AVR. So you must allow for them to be different, although they may of course be identical sometimes.
As for me, regarding gcc version, if something works poorly it should be reported to upstream maintainers instead of sitting on old out-dated version.
This is ideal and wishful thinking. There is only one avr-gcc developer, and he is doing a superb job at fixing bugs. Of course do report it upstream, but because of a lack of developer power a fix may be 3 years away no matter the bug priority. Meanwhile you can't not have a working compiler for everyone, so you must patch if possible. Or there is no patch - in which case you can't upgrade gcc to/with mainstream and you must stay with the older version. In embedded systems it is frequently more important to have a compiler with known rather than best characteristics. Suddenly your car brakes fail because someone changed to a newer compiler that has one bug fixed that didn't affect the break code but does something else that makes the brake code fail. Well Arduino doesn't make car brakes (thank goodness, the code is low quality) but it's used many times by users who don't want or need to know about compilers and you have to be careful not to change their end result. Code size is also critical in embedded systems. In my experiments size almost always went up substantially from 4.3 to 4.5, and sometimes from 4.3 to 4.6. It's only easy to find out if you have all versions installed. Volker -- Volker Kuhlmann http://volker.dnsalias.net/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, 23 Oct 2013, Matwey V. Kornilov wrote:
2013/10/23 Richard Biener <rguenther@suse.de>:
On Wed, 23 Oct 2013, Juergen Weigert wrote:
On Oct 23, 13 10:55:20 +0200, Richard Biener wrote:
Unused in the GCC package, AVR support was moved to a separate package at some point in time.
I did that move when an old compiler was the better choice. Should we go back into the main GCC package if we find that now a current GCC is a good choice? (Chances are high that 4.8 is an excellent avr compiler, I am told...)
Seems, I am able to compile devel:gcc/gcc48 for avr with minimal changes, but some cleanups are still required.
If you are happy with it just do a submitrequest - I'll probably manually integrate it doing my share of cleanups.
As for me, regarding gcc version, if something works poorly it should be reported to upstream maintainers instead of sitting on old out-dated version.
Agreed. Richard. -- Richard Biener <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
24.10.2013 12:31, Richard Biener пишет:
Seems, I am able to compile devel:gcc/gcc48 for avr with minimal changes, but some cleanups are still required.
I've broke everything trying to merge with the latest devel:gcc/gcc48 :(( Trying to fix -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 24.10.2013 20:27, Matwey V. Kornilov wrote:
24.10.2013 12:31, Richard Biener пишет:
Seems, I am able to compile devel:gcc/gcc48 for avr with minimal changes, but some cleanups are still required.
I've broke everything trying to merge with the latest devel:gcc/gcc48 :((
Trying to fix
Ok, http://download.opensuse.org/repositories/home:/matwey:/branches:/devel:/gcc... Unfortunately, I am not able to reach my hardware now and in the closest time, so hope somebody will test what code this compiler actually produce. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon 21 Oct 2013 22:36:42 NZDT +1300, Juergen Weigert wrote:
We wanted to get rid of the 'cross-' prefix at some point. I personally do not care so much about naming, and did not check if this move was ever completed. Probably not.
No it wasn't, but it's not difficult. It requires someone with write access to the AVR repo to do it for several packages at the same time, and to adjust dependencies and vuild dependencies. It might pay to put in an extra provides with the "cross-" prefix until all packages are changed. The best time to do this might be with a clean-up, like now, together with a move from /opt to /usr. Volker -- Volker Kuhlmann http://volker.dnsalias.net/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Oct 24, 13 10:15:50 +1300, Volker Kuhlmann wrote:
No it wasn't, but it's not difficult. It requires someone with write access to the AVR repo.
Volker you now have write access! Enjoy! cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 say #263A!__/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Jeff Hawn, J.Guild, F.Imendoerffer, HRB 16746 (AG Nuernberg), Maxfeldstrasse 5, 90409 Nuernberg, Germany SuSE. Supporting Linux since 1992. ☺ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (5)
-
Juergen Weigert -
Matwey V. Kornilov -
Matwey V. Kornilov
-
Richard Biener -
Volker Kuhlmann