Who is the originator of the avrlibc packages? Is that Atmel or Free Software Foundation? Where does one submit bug reports and changes for that package?
And how does one submit bug reports changes to Arduino for V0022? In my other forums, this would have been picked up by a forum moderator, but here that does not happen.
In my other forums, this would have been picked up by a forum moderator, but here that does not happen.
Here, "forum moderators" are just that.
IDE bugs are not our responsibility.
There is, however, a section of forum for them:
http://arduino.cc/forum/index.php/board,21.0.html
Do you want me to move this post there for you?
Thank you, AWOL! It was just a bit confusing.
And what happens there that is different from this section? Who will read it there?
And the avrlibc? Same place?
EDIT: Yes, if you would move this to that section of the forum.
Here are a couple bugs I found last week. One in avrlibc-1.7.1 and the other in Arduino-0022.
For those compiling/installing avr-gcc v4.5.1 with avrlibc-1.7.1, the bugs are here:
Bug #1
avrlibc-1.7.1/include/util/delay.h.in
At line 44, add this:
#include <math.h>
This is required due to the calls to fabs() and ceil() in the delay.h file.
If you are using a precompiled version from a repository or download from Atmel, you can "retro" this fix by adding the same line to your current delay.h file.
/usr/../avr/include/util/delay.h
My repository installed it in "/usr/avr/include/util/delay.h", but that could vary by version of Linux and the repository. Some may be "/usr/local/".
Bug #2
arduino-0022/hardware/arduino/cores/arduino/wiring.h
Remark out line 79 (round macro). This causes a problem with the avr-gcc math.h library when you add the include to delay.h.
// #define round(x) ((x)>=0?(long)((x)+0.5):(long)((x)-0.5))
Now the compiler should compile most code correctly.
The ethernet shield has a bug.
http://arduino.cc/forum/index.php/topic,68624.0.html
SurferTim:
Who is the originator of the avrlibc packages? Is that Atmel or Free Software Foundation? Where does one submit bug reports and changes for that package?
Well, if you go to (on my system, other distros might have it in a different spot) /usr/share/doc/avr-libc and look at the README file, it will point you to:
The Free Software Foundation is more of an advocacy group. They aren't what I would call 'originators', though many developers are members, I assume. However, Free Software is really a huge collection of individual contributions. Thus, the originators are the original authors of the code. But those people aren't necessarily members of FSF.
ETA: Also, avr-libc is released under a modified BSD license, so it's "free" software, but I don't know whether it meets the GNU definition for "free". Yeah, silly nitting to some. 
Hi justjed. Thanks for the info. Anything helps at this point.
I think I got the avrlibc-1.7.1 libraries from savannah.nongnu.org when I found the bug in the compiled version. I know it is open source, and many people probably contributed, but I was hoping there would be remnants of that group around somewhere, and a central repository where the "official" version was located, so I guess that site is it?
So how does Atmel figure into this? They don't have their own compiler for their processor? They don't check to see if the code will compile anything before advertising it and offering it for download on their website?
I have a lot of programming experience, but not much with the open source community. I am not familiar with how some of this works. Since I have a change now, should I just create and upload my own new version? Like avrlibc-1.7.2?
And about the bug in the Arduino code? Same there? I just make up my own new version? Arduino V0023?
EDIT: I have joined the savannah group for the avrlibc project and submitted the change.
SurferTim:
I think I got the avrlibc-1.7.1 libraries from savannah.nongnu.org when I found the bug in the compiled version. I know it is open source, and many people probably contributed, but I was hoping there would be remnants of that group around somewhere, and a central repository where the "official" version was located, so I guess that site is it?
I think so. That's the best I can tell, and there's at least activity on the mailing list.
So how does Atmel figure into this? They don't have their own compiler for their processor? They don't check to see if the code will compile anything before advertising it and offering it for download on their website?
I wish I knew. Vendors are quite varying in their contributions to Free Software. Some, such as IBM, contribute a lot. Oracle is a mixed bag, but they've contributed. Nvidia, AMD, Intel have made varying degrees of contribution. Last I looked -- admittedly quite a while back, Intel had their own C compiler for Linux, but they also at the least gave advice on things such as optimizations.
I have a lot of programming experience, but not much with the open source community. I am not familiar with how some of this works. Since I have a change now, should I just create and upload my own new version? Like avrlibc-1.7.2?
And about the bug in the Arduino code? Same there? I just make up my own new version? Arduino V0023?
EDIT: I have joined the savannah group for the avrlibc project and submitted the change.
Cool. You've taken part. And this, really, is part of the backbone of how this works. I've mentioned Eric S. Raymond's description of the Open Source community as a 'gift economy'. How it works is that people get software free, and if they have something to contribute, they give back. That can take the form of good bug reports, being a beta tester, writing docs, writing code, or even just donating money to support a product. Or helping out in support forums.
You can, in fact, make your own version. There's a process known as 'forking', which I won't go into in any detail, but it doesn't happen a lot. The canonical example, I suppose, is Emacs vs. Xemacs. The other really big fork recently was Xorg from X11. But most people will not fork a project until they've tried to work within the existing one. And, it's easier to submit your patch or suggestion, than it is to start hosting your own project anyway. Of course, if your patch is rejected, well, that's a bummer, but there might be a good reason for it too.
Thanks, justjed. I really appreciate your insight to all this. The bug and fix has been posted on the bug list page, but no action has been taken on it. It appears it could be months before this bug is reached by the dates on the bug list. There are 28 there, and the progress appears to be slow. I'm hoping since there is also a fix, it will be approved/disapproved quicker.
The bug fix for this is a "no brainer". Like this code. I posted all of it. Yes, I "forgot" something. What is wrong? Why does the compiler not like the call to SPI.begin()? Why does it tell me SPI was not declared?
void setup()
{
SPI.begin();
}
void loop()
{
}
EDIT: If I suggested that the reason was "you forgot the #include <SPI.h> at the top", would anyone here argue about that?
If you take a look at one of the major reasons for the release of avr-libc 1.7.1 was to correct a flaw in timing accuracy of the delay.h functions in v1.7.0. They now use fabs() and ceil() in most of the delay functions for the timing. Those are float math functions. They are declared in math.h.
They just left out one include. No thing. Been there, done that...
If you are interested, this is where bugs are reported for th AVR C runtime library:
SurferTim:
Thanks, justjed. I really appreciate your insight to all this. The bug and fix has been posted on the bug list page, but no action has been taken on it. It appears it could be months before this bug is reached by the dates on the bug list. There are 28 there, and the progress appears to be slow. I'm hoping since there is also a fix, it will be approved/disapproved quicker.
You're welcome.
Progress can be slow, particularly if all the maintainers (or the only maintainer, in many cases) has a full-time job and works on the project as a side thing. I've seen projects that ended up going nowhere, because the maintainer just didn't have time, or lost interest. The good thing about Free Software is that when that happens, other people can pick it up and run with it.
I do find it a bit disconcerting that there are that many bugs which have no status, and are unassigned. But it could be that there are only a couple people working on it, so, nobody to assign bugs to, who isn't already carrying a full load.
The good thing is that the bug report is there, and findable by anyone having the same problem.
The usual solution to avr-gcc or avr-libc bugs is to go back to a version where the bugs did not occur, rather than to patch the latest version manually (after having submitted a bug report, of course.)
I believe Arduino for Windows and Mac is shipping with avr-libc 1.6.7 for example (via winavr and avr crosspack packaging efforts.)
Atmel has someone defined to interface with open source software. Apparently a big responsibility is to package up WINAVR with components that are supposed to work together.
Thanks for the advice, but I am on Arduino 0022, avr-gcc 4.5.1, and avr-libc 1.7.1. I have it patched and that is where I am staying. If I find more bugs, I'll try to get them fixed too. Somebody has to do it, or we would still be using MS-DOS 3.1.
I am not recommending everyone jump up to these new versions, but the experienced users (especially Arduino and Atmel) should give it a try, at least to report the bugs.
I have already found another bug. This one in the Ethernet library. I think this one is Arduino tho. How do I report bugs to Arduino? Posting the bug here is obviously not it.
I'll let you know when it is "safe" to upgrade. 
ADD: I don't expect immediate results. It is obvious by now that none of the Atmel or Arduino people have tried the new versions. How could you miss the delay.h bug?
I see this:
Atmel has someone defined to interface with open source software. Apparently a big responsibility is to package up WINAVR with components that are supposed to work together.
...and I see this:
I do find it a bit disconcerting that there are that many bugs which have no status, and are unassigned. But it could be that there are only a couple people working on it, so, nobody to assign bugs to, who isn't already carrying a full load.
Why doesn't the Atmel crew send a programmer over to the Savannah site and give those two guys some help? If I knew more about the other bugs, I would help. I need a little more exposure to this processor tho.
And that could be unfair, because that list is only open bugs. I can't seem to find how many have been corrected in that time. I'm still looking.
SurferTim:
I see this:Atmel has someone defined to interface with open source software. Apparently a big responsibility is to package up WINAVR with components that are supposed to work together.
...and I see this:
I do find it a bit disconcerting that there are that many bugs which have no status, and are unassigned. But it could be that there are only a couple people working on it, so, nobody to assign bugs to, who isn't already carrying a full load.
Why doesn't the Atmel crew send a programmer over to the Savannah site and give those two guys some help? If I knew more about the other bugs, I would help. I need a little more exposure to this processor tho.
This is how it goes though. Some people would say that that's part of the 'price' of free software. I don't agree with that, because even with commercial software, there are bugs which languish, sometimes for years. At least with free software, you can fix it yourself.
but the experienced users (especially Arduino and Atmel) should give it a try, at least to report the bugs.
Note that for windows and Mac, the compiler and library all come pre-packaged within the Arduino install. It's only on linux that anyone has to manage compiler/library versions separately. There's something to be said for installing the latest versions, and a different something to be said for running the same code everyone else is stuck with. Pick and choose.
Why doesn't the Atmel crew send a programmer over to the Savannah site and give those two guys some help?
Ah. You say that like you think Atmel must have more or better programmers than the Savannah site. But Atmel is a hardware vendor, and that's not sure to be true. Once you read enough app notes and such, and start analyzing the code that's published, your opinion might change... I know I've developed a low opinion of the serial bootloader protocols that Atmel has published, since I've been working on them.
Arduino has its own Google Code page where bugs can be submitted.
At least with free software, you can fix it yourself.
"Free" is neither necessary or sufficient for being able to "fix it yourself." Universities and capable customers have had "source licenses" for otherwise proprietary (and expensive) software, and been fixing their vendors' bugs, since ... forever.
Ah. You say that like you think Atmel must have more or better programmers than the Savannah site.
What was I thinking? If they did not check the code to insure it worked before posting it on their website, what can I expect from them as programmers?
Thanks to all for the input. It makes more sense now.
I'm still searching for the cause of the ethernet bug. Maybe I'll find it too. That is the only bug remaining that is affecting my programs. But it is not nearly as easy to find as the delay.h bug.
I have already found another bug. This one in the Ethernet library. I think this one is Arduino tho. How do I report bugs to Arduino? Posting the bug here is obviously not it.
Why do you say that? To get bugs fixed, it is usually helpful to spread a much information about the bug as widely as possible. Usual procedure:
Post information in the appropriate section of the forums, see if other people experience the same problem, already have a workaround, or whatever.
If confirmed, and it's an arduino bug, create an "issue" at the google code site. Notify the arduino "developers" mailing list as well. If in gcc or avr-libc, consider moving the discussion to avr-freaks and/or the appropriate mailing list.
Debug and poke to the limits of your ability, patience, and desire. If you develop a patch or workaround, attach it to the official "issue."
Develop a thick skin. Some issues are more complex or difficult to fix than you might think, and the people in charge aren't always very god at explaining themselves. (The last avr-gcc g++ bug I submitted took 7 months to get a "won't fix - it's not supposed to work the way you want it to" response. Sigh.)
My bad. I should have posted the link to the issue with that statement.
http://arduino.cc/forum/index.php/topic,68624.0.html
I would have submitted these issues in the appropriate places had I known. It took two weeks before someone (thanks again, justjed) steered me to the Savannah site.
Now the big question. Is anyone else using avr-gcc v4.5.1?
I'm ok with being "the only one". I'm comfortable being the lead dog in the pack.
westfw:
At least with free software, you can fix it yourself.
"Free" is neither necessary or sufficient for being able to "fix it yourself." Universities and capable customers have had "source licenses" for otherwise proprietary (and expensive) software, and been fixing their vendors' bugs, since ... forever.
And how wonderful it is that Free Software and Open Source have provided that capability to everyone, not just those who have deep pockets for buying source licenses.
I'm comfortable being the lead dog in the pack.
That's good, because unless you are the lead dog, the view is always the same. 
Lefty
I found the ethernet problem and have posted all the bugs and fixes with Arduino and Savannah.
http://code.google.com/p/arduino/issues/detail?id=604&start=200
http://code.google.com/p/arduino/issues/detail?id=605&start=200
It is good to be back in a Linux environment again. All seems to be working great.
Arduino V0022
avr-gcc v4.5.1
avr-libc v1.7.1
gcc v4.5.2
I received notice this morning from the Savannah crew that the math.h bug in delay.h will be corrected in avr-libc v1.7.2
One down, two to go! 