Re: [avr-gcc-list] Experiences to build avr-toolchain using latest stable versions.

[Clemens Koller]

Hi, Joerg!

Joerg Wunsch wrote:
> Clemens Koller <address@hidden> wrote:
> > 2a. usually optional: gmp-4.2.1:
>
> Supposedly, this (and MPFR) is optional.  The configure only tried to
> configure with GMP as it found an existing gmp.h file in your
> installation.  If I read the configure script correctly, --without-gmp
> should work.  Did you try that?

No, I just installed GMP and MPFR... because I was curious of what
it is and whether I can need it. :-)

> (I've got no idea what they are using the GMP library for.)
> If it is configured without GMP, MPFR will not tested at all.

Fine... I can check that next time.

> > ../gcc-4.1.1/configure  --target=avr \
> >                        --enable-__cxa_atexit \
> Curious, what exactly is that for?

http://gcc.gnu.org/install/configure.html mentions:
--enable-__cxa_atexit
Define if you want to use __cxa_atexit, rather than atexit,
to register C++ destructors for local statics and global objects.
This is essential for fully standards-compliant handling of
destructors, but requires __cxa_atexit in libc. This option is
currently only available on systems with GNU libc. When enabled,
this will cause -fuse-cxa-exit to be passed by default.

I have no glue of what this could mean for the avr. (I doubt it's
necessary) But I ran into very hard to debug problems on my
powerpc system long time ago compiled without the -fuse-cxa-exit.
The topic there is C++ ABI compliant behaviour:
http://gcc.gnu.org/gcc-3.2/c++-abi.html
http://www.codesourcery.com/cxx-abi/

> > 4a. uisp-20050207:
> AFAICT, UISP is no longer maintained.  I suggest dropping that in
> favour of AVRDUDE.

Jep... I just couldn't decide of which one I am going to use more.

> > Are there any plans to fix dwarf2 in the future?
>
> The fix that is indirectly mentioned in the bug report is known to
> work (at least, there have been no reports of failure so far).
>
> What do you need DWARF-2 for?

Old projects/makefiles? As a newbie you crash into that
pretty often. (when start using AvrX i.e.)

> It's almost unmaintained for the AVR
> target.  GDB cannot really use it (e. g. it starts to confuse RAM and
> ROM addresses, I didn't try much harder, I guess it will get
> completely messed up when it comes to stack frame tracing), the entire
> DWARF-2 has been implemented completely aside the binutils anyway (so
> you cannot e. g. convert between DWARF-2 and stabs using avr-objcopy),
> the assembler cannot generate DWARF-2 line number information when
> configured for the AVR (several important DWARF-related sections are
> missing in the output when you run it with --gdwarf2).  So far, the
> only known happy consumer of AVR-GCC's DWARF-2 is Atmel's AVR Studio,
> but I don't believe you're an AVR Studio user.

I'm not, but there are some users in the company which are much more
comfortable with a one-in-all IDE. (Yes, WinAVR is good, too, but...)

> For the GNU tools,
> stabs debugging still works way better for the AVR target.

No problem here, as long as someone can come to a conclusion as the
one you give here.

Thank you for your comments!

Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19