I agree that perhaps a FAQ is necessary. Interestingly though, the
questions discussed below are in multiple domains; not only AVR GCC and
Unix newbie, but C language and embedded programming.
For example, as you mentioned, the typical question about a missing
'volatile' is more of a C language issue or an embedded programming issue.
When learning C, one is supposed to learn what the 'volatile' keyword is
for and how and when it gets used, such as in optimized sections or in an
interrupt service routine. Granted, that one generally only gets exposed
to writing ISRs when programming for embedded systems.
The problem that started this thread has more to do with the ability
to interpret linker error messages. I ran into the same problem myself
with a different math function. I called the function, included the right
header file, knew that I was linking in the "standard C library", and
voila: I got a linker error saying it can't find the function. "So perhaps
they're in a different library?" I thought. Sure enough, libm.a looks like
it might be a math library, I link it in and it works. Now it becomes a
Unix newbie programming issue: I've done all my embedded programming work
the last 7 years on a Windoze platform. I had no idea that the "standard C
library" was in 2 files. Much less, I'm not used to a library being called
an "archive" and having a .a file extension, I'm used to a library with a
.lib extension. An archive in my mind is a backup.
Now, I don't want to give the impression that I'm complaining. After
all, I know that GCC comes from a Unix background. I expect differences,
quirks even. I've been doing as much digging for information about it as I
can from whatever source I can and it's all worked for me. I haven't even
had to resort to asking the list for help and my 15,000 line+ project has
been coming along fine and I think the AVR-GCC compiler is great!
What I did like about AVR Freaks was their creating the Windoze
binaries and packaging in an installation. That's nice if you're new to
GCC. There's a learning curve with any compiler; much more if you have to
build it from the source yourself. I'll admit that I'm more interested in
using the compiler than having to build it.
I agree that the AVR Freaks makefiles are overly complicated, but for
a different reason. I don't like there are 2 makefiles and that AVR Freaks
is unnecessarily hiding the main functionality. IMO, make and
makefiles aren't so complicated in what they do that it requires
insulating the user, which is a programmer, who should be used to
dealing with a certain level of complexity anyway.
As a side note, I would put forth the argument that any program
should not make a distinction between TABS and SPACES. They are both
non-printable characters and in most editors (at least on Windoze) it
requires an effort to tell them apart. There are always other means to
achieve the desired functionality.
After talking with Sander Pool off-line, I understand the reason
for seperate libraries: Unix history. But...is it still justified in
having that seperation? What is the down side in combining them? The down
side in leaving them seperated is more questions like the one that started
So perhaps a general AVR GCC FAQ is needed.
Date: Friday, July 26,
2002 04:19:37 AM
[avr-gcc-list] strange behaviour with ceil()
"E. Weddington" <address@hidden> wrote:
When migrating to AVR GCC from another compiler (like I have
recently), how / where is one supposed to find out that the
standard C math routines are in a seperate library file?
FAQ (not only for AVR-GCC but for Unix newbie programmers as
same like the typical question about a missing `volatile'
So basically, we probably need a FAQ that is
referenced from all
locations where one could obtain AVR-GCC
OK, the requirement for having a libm.a separate from libc.a
rather a Unix historical artifact, and one could argue that both
easily be incorporated into a single libc.a as
> I applaud AVR Freaks for trying to make the compiler
easy to install
> and use (it worked for me at any rate), but a
> documentation would help.
To be honest, i
always found the AVR Freaks Makefile templates overly
some respects, it's even dangerous in that it
encourages people to
employ a bad Makefile style that is at the risk
of becoming buggy, like
with their variable name indentation to
right-align them at the equal
sign: you /must/ use spaces to indent
them, if you use a TAB, Makefile
syntax mandates that a TAB is
introducing a shell command, and some
implementations will simply
complain about it. So it would be better to
simply start all variable
names flush left.
My typical AVR
project Makefile doesn't have more than 50 lines, where
i copy about
half of it as a `template' from another old project, and
remainder for the actual filenames in my new project. But
then, i come
from a Unix background, so compiler flags and arguments
as well as the
use of `make' is quite common to me.
However, the risk of those
large template buildings is that you never
really learn how `make' is
working, and are at the end of your road as
soon as you encounter a
situation which is not covered by the
template. So i'd rather encourage
people to not only study the
compiler documentation, but that of `make'
as well. (Of course, i
have no clue whether the texinfo documentation
of gcc and make is
actually included and easily readable in the Windows
J"org Wunsch Unix support