Forum: µC & Digital Electronics Did anybody ever succeed in compiling Atmels patched avr-gcc?

von matrixstorm (Guest)

Rate this post
0 useful
not useful
Hi commumity.

Did anybody ever succeed in compiling Atmels patched toolchain from 


(Obviously Atmel has, since their x86 binaries are operational.)

It seems so full of (intentional?) bugs.
Even starting with binutils, there are declarations missing...

Does anybody have some ideas? Is there some other URL with patchfiles?

Thanks to all of you.

BR matrixstorm

von Achim K. (aks)

Rate this post
0 useful
not useful
I also tried it under Ubuntu 12.04 for Toolchain 3.4.3 ...
and gave up without success :-).

von matrixstorm (Guest)

Attached files:

Rate this post
1 useful
not useful
Hi again.

I was lucky enough to get binutils patched, finally.
(I attach my patch here.)

However it remains a mystery to get the gcc or even their patched 
avrlibc compiled.

For any suggestions I would be really helpful.
Otherwise a shitstorm would be ok, too.
At least then I know I am not the only/ a completly twit.

BR matrixstorm

von batchman (Guest)

Attached files:

Rate this post
0 useful
not useful
Using mingw32 on XP(SP3), I found several reasons causing the 
compilation to fail, but finally the build runs through.
http://www.nongnu.org/avr-libc/user-manual/install_tools.html gives some 
useful information about a manual building process and lists required 

a) mingw basic setup
Download the current release of mingw using the installer
(installation path should not contain blanks; I've used F:\mingw)

Basic Setup - checked

All Packages - checked additionally

All Packages - uncheck (in need of another version)

b) mingw modifications
Create \mingw\msys\1.0\etc\fstab to reflect the actual installation 
path. See http://www.mingw.org/wiki/Getting_Started

Replace F:\mingw\var\lib\mingw-get\data\mingw32-autoconf.xml with the 
version attached or change it manually to point to autoconf2.5-2.64-1.

Using a newer version is the primary error source while creating 
avr-binutils. Changing some path variables (like for other problems) 
would probably fix it too, but the script insists on using 2.63/2.64.
Check in mingw32-autoconf2.5 using mingw-get.exe again.

Create a shortcut to F:\mingw\msys\1.0\msys.bat

c) Install prerequisite programs
pdflatex epstopdf
I've used 
Using the installer automaticly expands the windows path variable.
will be downloaded on first use.

pngtopnm and various other conversion tools
Tired of fumbling around with installations, I simply extracted the 
w32-binaries from
netpbm-10.27-bin.zip and netpbm-10.27-dep.zip respectively.
and put them together in newly-created /usr/local/bin 

Extracted gdiplus.dll and fig2dev.exe to /usr/local/bin

Extracted doxygen.exe and doxytag.exe to /usr/local/bin

I'd already installed version 9.02, seems working
(no problem with dir containing blanks)

d) Setup the sources
I've used F:\mingw\msys\1.0\home\username\avr as base directory. Below 
there are
./build, ./install, ./source, ./source/headers, ./source/gmp, 
./source/mpfr and ./source/mpc containing the tarballs.

e) Modify the installation script.
All further problems (*) are caused by using absolute paths, which are 
not supported in all cases.
Simply changing all variables ($srcdir, $builddir, $LIB_DIR...) to 
either "/home/username", "F:/mingw/msys/1.0/home/username" or 
"/f/mingw/msys/1.0/home/username" leads to unexpected behavior in 
otherwise working parts.
Also, using strictly relative paths would require too much changes.
Thus introducing a new variable srcdirw=$(cd ${srcdir}; pwd -W) used by 
previously failing configure calls works well.
There are discussion about this topic in general, some of them 
discourage the use of pwd -W, but who cares. I'm not convinced that this 
longstanding problem would be ever solved by the root, because there are 
a lot of compatibility issues in executables, scripts and the m4 macro 

So use the attached version copied to ~/avr, cd to this dir and start 
the build process.
$ sh build-avr8-gnu-toolchain-git-msys.sh -b ./build -p ./install -s 
Depending on your hardware, this could take serveral hours.

gcc_build_full(), gcc_build_bootstrap() -> fails during build
build/gengtype.exe  \
                    -S /home/username/avr/source/gcc/gcc -I 
gtyp-input.list -w tmp-gtype.state
/home/username/avr/source/gcc/gcc/../libcpp/include/line-map.h: No such 
file or directory
even if the file is available.

gmp_build() -> fails at configure
checking size of mp_limb_t... 0
configure: error: Oops, mp_limb_t doesn't seem to work

von funlw65 (Guest)

Rate this post
0 useful
not useful
Why not just using their avr toolchain for Linux? If there is so much 
trouble, personally I prefer to let Atmel doing that job. I just 
download, install and use :) .

von matrixstorm (Guest)

Rate this post
0 useful
not useful
Thx batchman.

Using my binutils patches I finnaly managed to compile the rest of the 
toolchain, too.

funlw65 wrote:
> Why not just using their avr toolchain for Linux?

Perhaps because Atmels toolchain is limited to x86(_64)?

And I would like it to have it on some other CPU arch ( no, not ARM ;-) 

BR matrixstorm


Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]

Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.