www.mikrocontroller.net

Forum: Compiler & IDEs AVR - GCC 4.3.3 / LIBC 1.6.5 build - komplett


Autor: wope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

habe mit Hilfe mehrerer Anleitungen und Forenbeiträge nach diversen 
"make errors" meinen eigenen "build" der AVR tools für Linux geschafft. 
Leider ist es immer etwas mühsam, alles zusammenzuklauben.

Ich erlaube mir, den ganzen Build/Installprozess für das aktuelle 
Tooling komplett darzustellen --> "yet another installation aid"...

Ist gedacht, Zeile für Zeile in die Shell zu kopieren. Das Ergebnis ist 
ein Verzeichnis mit allen Tools, das man auch zentral halten kann statt 
alles in die Distribution zu schaufeln...

GCC und Standard-Entwicklungstools wie Make & Co für Linux müssen 
bereits vorhanden sein (aber nicht unbedingt so aktuell...)

Zum Verwenden des Toolings später braucht man dann nur ein paar 
Variablen setzen:

PATH=/usr/local/atmel/bin:$PATH
export PATH
C_INCLUDE_PATH=/usr/local/atmel/avr/include:/usr/local/atmel/include:$C_ 
INCLUDE_PATH
export C_INCLUDE_PATH
LD_LIBRARY_PATH=/usr/local/atmel/avr/lib:/usr/local/atmel/lib:$LD_LIBRAR 
Y_PATH
export LD_LIBRARY_PATH

Hab's danach z.B. mit Ulrichs Radigs Webservercode getestet, bei mir 
haut es hin!

Liebe Grüße,
WoPe

#==========================================
# we need this directory for building only, you may remove that stuff 
later again
mkdir tools
cd tools/
# adopt the directory to your download directory
# check here: ftp://gcc.gnu.org/pub/gcc/infrastructure/
tar xvjf ../Downloads/gmp-4.2.1.tar.bz2
tar xvjf ../Downloads/mpfr-2.3.0.tar.bz2
# check here: http://ftp.gnu.org/gnu/binutils/
tar xvjf ../Downloads/binutils-2.19.1.tar.bz2
# check here: http://ftp.gnu.org/gnu/gcc/gcc-4.3.3
tar xvjf ../Downloads/gcc-core-4.3.3.tar.bz2
# check here: http://www.very-clever.com/download/nongnu/avr-libc/
tar xvjf ../Downloads/avr-libc-1.6.5.tar.bz2

# this is the directory everything goes in....
sudo mkdir /usr/local/atmel
# this is not really needed, but who cares :-)
sudo mkdir /usr/local/atmel/bin
sudo mkdir /usr/local/atmel/include
sudo mkdir /usr/local/atmel/lib

# I don't want to have this stuff with root rights,
# so we spare later to do a sudo make install...
sudo chmod -R a+wX /usr/local/atmel

# adopt pathes for separate build/installation
# you may not need this and the previous lines when removing all
#   the --prefix options below and thus installing into (default)
#   directory /usr/local/*
PATH=/usr/local/atmel/bin:$PATH
export PATH
C_INCLUDE_PATH=/usr/local/atmel/include
export C_INCLUDE_PATH
LD_LIBRARY_PATH=/usr/local/atmel/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

# required prerequisites
cd gmp-4.2.1/
./configure --prefix=/usr/local/atmel
make
make install

cd ../mpfr-2.3.0/
./configure --prefix=/usr/local/atmel --disable-shared
make
make install

# required utilities for AVR binaries
cd  ../binutils-2.19.1/
./configure --prefix=/usr/local/atmel --target=avr 
--program-prefix="avr-"
make
make install

# add further pathes...
C_INCLUDE_PATH=/usr/local/atmel/avr/include:$C_INCLUDE_PATH
export C_INCLUDE_PATH
LD_LIBRARY_PATH=/usr/local/atmel/avr/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

# now we compile the AVR gcc
cd ..
#obj in src dir not well supported (causes make error)
mkdir gcc_obj
cd gcc_obj
#libssp must be disabled, as it requires POSIX OS a "blank AVR" does not 
have(causes make error)
../gcc-4.3.3/configure --prefix=/usr/local/atmel --target=avr 
--program-prefix="avr-" --enable-languages=c --disable-libssp
make
make install

# without this library, you won't have much fun using the AVR...
cd ../avr-libc-1.6.5/
./configure --prefix=/usr/local/atmel --build=`./config.guess` 
--host=avr
make
make install

# finally make the installation readonly...
sudo chmod -R a-w /usr/local/atmel

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wope wrote:

> habe mit Hilfe mehrerer Anleitungen und Forenbeiträge nach diversen
> "make errors" meinen eigenen "build" der AVR tools für Linux geschafft.
> Leider ist es immer etwas mühsam, alles zusammenzuklauben.

Ist leider dahingehend ein wenig schade um die Arbeit, dass insbesondere
der GCC viele Patches benötigt, da die Release-Version stets deutlich
hinter dem aktuellen Entwicklungsstand hinterher hinkt.  Insbesondere
sind seither mehrere dramatische Bugs (also solche, bei denen
stillschweigend fehlerhafter Code generiert wird) repariert worden.

Autor: wope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Info. Mit dem, was man in den Linux-Distis findet, bin ich 
aber auch nicht glücklich geworden, die sind ja z.T. noch älter...

D.h. man sollte sich die Sourcen von GCC direct mit SVN direkt 
gcc.gnu.org abziehen? Sind die besser?

Oder gibt es eine gute Quelle für die erwähnten Patches? Im CVS von 
Winavr findet man z.B. patches gegen 4.3.2. -  mein (ok etwas naiver) 
Gedanke war, dass die im 4.3.3. dann schon (zumindest teilweise) 
eingearbeitet sind. :-/

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: wope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das beantwortet meine Frage auch nicht. Ich bin auf der Suche nach dem 
"Ursprung" des avr-gcc, also von den "Maintainern" des AVR compiler 
targets. Eine Distribution brauche ich nicht, dann kann ich ja gleich 
Windows verwenden.  :-)

Nein, Spass beiseite: wenn ich das richtig verstanden habe ist die beste 
Quelle auch für Linux die Sourcen der GCC Version des WinAVR + Patches 
vom Winavr SVN zu nehmen, wie es auch die Debian-Leute machen. Richtig?

Danke im Voraus!

Autor: wope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe gerade versucht die Patches vom WinAVR zu verwenden, die am 
Sourceforge zu bekommen sind. Habe natürlich die entsprechenden 
Sourcecode-Versionen verwendet, auf die die Patches verweisen.

Leider wird beim Patchen auch IMHO was "kaputt" gemacht (?), denn ohne 
Patches hat ein build ohne Fehler geklappt, nach dem Patchen vermissen 
die sources da und dort z.B. ein #include <limits.h>. Könnte auch an 
einem kaputtrepariertem configure liegen.

Mannomann - das ist definitiv viel mühsamer als mit manch anderen 
Tools/Toolchains. Bin schon wieder den halben Tag am Graben, was da 
alles gepatcht wird, um den avr-gcc nach letztem Stand (!) sauber 
aufzusetzen.

-->

Gibt es nun irgendwo Links zu aktuellen avr-gcc Sourcen oder 
konsistente/vollständige Patches zu den "offiziellen" gnu.org Sourcen, 
um sich (wie unter Linux/Opensource üblich) Tools selbst von Zeit zu 
Zeit zu bauen?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem ist, dass das GCC-Projekt ziemlich langsam in den
Verfahren ist, mit denen man dort neue Dinge oder selbst Reparaturen
einpflegen (lassen) kann.  Dadurch gibt es praktisch immer eine Zahl
von `outstanding patches' für den AVR-GCC, das ist praktisch ein
Dauerzustand -- und sei's nur, um mal wieder für die neuesten AVRs
die Namen bekannt zu machen.

Autor: W. S. (wope)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> Das Problem ist, dass das GCC-Projekt ziemlich langsam in den
> Verfahren ist, mit denen man dort neue Dinge oder selbst Reparaturen
> einpflegen (lassen) kann.  Dadurch gibt es praktisch immer eine Zahl
> von `outstanding patches' für den AVR-GCC, das ist praktisch ein
> Dauerzustand -- und sei's nur, um mal wieder für die neuesten AVRs
> die Namen bekannt zu machen.
Ok, ist auch verständlich und würde mich nicht trauen, zu kritisieren. 
Gcc ist ja nicht nur für die AVR community da und das ist ja wirklich 
ein ganz schön dickes Softwareprojekt :-)

Ich finde es nur schade, dass die viele Arbeit, die in den Korrekturen 
von avr-gcc steckt nur für die Winavr (und wenigen Linux-Distributionen 
wie Debian?) aktuell verfügbar sind. Da hoffe ich, einen klitzekleinen 
Beitrag leisten zu können...

Ich gehe davon aus, dass die Patches am Winavr Sourceforge die sind, die 
tatsächlich diese (sehr bemerkenswerte) Arbeit am avr-gcc 
wiederspiegelt.

Darauf aufbauend habe ich meinen oben genannten build Prozess nochmal 
überarbeitet und mit ein paar Codebeispielen erstmal erfolgreich 
getestet. Habe es um Debugging/Programmingtools auch noch ergänzt.
Ziel: ein Build der a) nicht eine bestimmte Distri voraussetzt und b) 
eine beliebige Installation auf einem Filer ermöglichen sollte - vor 
allem hasse ich es, alles in /usr/bin, /usr/local/bin u.s.w. zu "müllen" 
- das ist ja schlimmer als Windows :-)

Da ich mit den aktuellen Patches am XMEGA leider keinen Erfolg hatte, 
habe ich diese Patches weggelassen. Dafür musste ich einen Patch 
zusätzlich generieren - habe ihn angehängt.

Ich hoffe es gibt noch andere, die sowas brauchen könnten. Viel Spass 
damit!

Möchte aber Anfänger in Sachen C, ./configure und Linux warnen: kleinste 
(!) Fehler/Unachtsamkeiten, und nichts geht mehr. Über ein paar Dinge 
bin ich auch gestolpert, die habe ich zumindest in diesem "Kochbuch" 
auch erwähnt...

Aber zuguterletzt: vielen Dank (größtenteils unbekannterweise) an alle, 
die an diesem GCC-AVR so viel Arbeit investieren!!!!

==============

# AVR-GCC build (latest available version used)
# =============================================
# date of downloads/build: 9th March 2009

# Needs:
# - some GCC compile environment (here I used gcc 4.1.2)
#   (binutils, make, gcc, ...) - usually a recent system which is
#   able to compile its own linux kernel/modules should be fine
# - further packages for the binutils/gcc build: gmp-devel, mpfr-devel
# - maybe some libraries, ./configure should tell you that (e.g. ncurses
#   for simulavr)
# - autogen is needed for "make check" with gcc build, but as it does
#   not check a lot, we leave it out
# - flex, yacc (or byacc, bison, ...) may be needed for building avrdude
# - wget or similar to obtain sources
# - cvs to obtain patches from Sourceforge
# - patch tool

# Don't run below lines as a script. Execute line by line and check for 
errors!

# The prefixing is exemplary, for central installations it might be any
# different mountpoint like "--prefix=/opt/avr_tools" or so...

# XMEGA support seems to be very "preliminary", so these patches are NOT
# included in this build...

#======================================================================= 
=======

# setup stuff, avoid later "make install" done as root
# (reduce risk that files are put into protected areas)
# =====================================================

sudo mkdir /usr/local/avr
sudo chmod a+wX /usr/local/avr
PATH=/usr/local/avr/bin:$PATH
export PATH
#C_INCLUDE_PATH=/usr/local/avr/include:$C_INCLUDE_PATH
C_INCLUDE_PATH=/usr/local/avr/include
export C_INCLUDE_PATH
LD_LIBRARY_PATH=/usr/local/avr/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
# check out that there is no single : is at the beginning or end of 
variables
# or that there is a sequence of :: (this seems to confuse ./configure 
or
# make or even gcc) - at least I figured out as I had defined following:
# "C_INCLUDE_PATH=/usr/local/avr/include:", causing errors later during 
gcc
# build, but "C_INCLUDE_PATH=/usr/local/avr/include" worked out fine!
# This caused really some headache :-)

# setup our build directory (temporary, not needed after build/install
# except all downloaded sources located also there...)
# ===================================================================

mkdir ~/avr_build
cd ~/avr_build

# obtain all patches from WinAVR repository
# =========================================

cvs -d:pserver:anonymous@winavr.cvs.sourceforge.net:/cvsroot/winavr 
login
# (press just enter for PW)
cvs -z3 -d:pserver:anonymous@winavr.cvs.sourceforge.net:/cvsroot/winavr 
co -P patches
cvs -d:pserver:anonymous@winavr.cvs.sourceforge.net:/cvsroot/winavr 
logout

#======================================================================= 
=======

# get/patch binutils for AVR and compile/install
# ==============================================

# we use the latest binutils
wget ftp://ftp.gnu.org/gnu/binutils/binutils-2.19.1.tar.bz2
tar xvjf binutils-2.19.1.tar.bz2
cd binutils-2.19.1
# this patches seem to be all important and work out well (also in 
2.19.1)
cat ../patches/binutils/2.19/30-binutils-2.19-avr-size.patch | patch -p0
cat ../patches/binutils/2.19/31-binutils-2.19-avr-coff.patch | patch -p0
cat ../patches/binutils/2.19/32-binutils-2.19-new-sections.patch | patch 
-p0
cat ../patches/binutils/2.19/33-binutils-2.19-data-origin.patch | patch 
-p0
# in 2.19.1. this patch is already applied, we don't need it anymore...
# --> cat ../patches/binutils/2.19/40-binutils-2.19-wrong-arch.patch | 
patch -p0
# xmega patches make troubles during build, leave them out for now,
# they also failed for me when patching against indicated 2.19 release
# (e.g. compile error for a not declared "bfd_mach_avrxmega1" and so on)
# --> cat ../patches/binutils/2.19/50-binutils-2.19-xmega.patch | patch 
-p0
# --> cat ../patches/binutils/2.19/51-binutils-2.19-xmega2.patch | patch 
-p0
# this patch just adds another MCU type, we can apply it without 
troubles...
cat ../patches/binutils/2.19/52-binutils-2.19-atmega32u6.patch | patch 
-p0
# make fails when ./configure and make is not started in src root 
directory!
# e.g. compile error for a not declared "TARGET" (seems due to the 
patches?)
# --> This is odd, because usually this way is not well supported due to
# some information on the web (preferred is to have a separate obj 
directory?)
./configure --prefix=/usr/local/avr --target=avr --program-prefix="avr-"
make
# not very exhaustive check :-)
make check
make install
cd ..
\rm -rf binutils-2.19

# get/patch GCC for AVR and compile/install
# =========================================

# all fixes could be applied to gcc 4.3.3 build succeeded...
wget ftp://ftp.gnu.org/gnu/gcc/gcc-4.3.3/gcc-core-4.3.3.tar.bz2
tar xvjf gcc-core-4.3.3.tar.bz2
cd gcc-4.3.3
# this patches seem to be all important and work out well (also in 
4.3.3)
cat ../patches/gcc/4.3.2/20-gcc-4.3.2-libiberty-Makefile.in.patch | 
patch -p0
cat ../patches/gcc/4.3.2/21-gcc-4.3.2-disable-libssp.patch | patch -p0
# ada not installed (would fail due to missing ada directory)
# --> cat ../patches/gcc/4.3.2/23-gcc-4.3.2-ada-Makefile.patch | patch 
-p0
# --> cat ../patches/gcc/4.3.2/40-gcc-4.3.2-bug-10768-by-adacore.patch | 
patch -p0
# we continue with important patches
cat ../patches/gcc/4.3.2/41-gcc-4.3.2-bug-11259_v3.patch | patch -p0
cat ../patches/gcc/4.3.2/42-gcc-4.3.2-bug-spill-v4.patch | patch -p0
cat ../patches/gcc/4.3.2/43-gcc-4.3.2-bug-35013.patch | patch -p0
cat ../patches/gcc/4.3.2/44-gcc-4.3.2-libgcc16.patch | patch -p0
cat ../patches/gcc/4.3.2/45-gcc-4.3.2-bug-33009.patch | patch -p0
# we add further MCU types here
cat ../patches/gcc/4.3.2/50-gcc-4.3.2-mega256.patch | patch -p0
cat ../patches/gcc/4.3.2/51-gcc-4.3.2-mega256-additional.patch | patch 
-p0
# don't do xmega pathes (also binutils lacks them), build would fail...
# cat ../patches/gcc/4.3.2/52-gcc-4.3.2-xmega-v9.patch | patch -p0
# cat ../patches/gcc/4.3.2/53-gcc-4.3.2-xmega2.patch | patch -p0
cat ../patches/gcc/4.3.2/54-gcc-4.3.2-atmega32m1.patch | patch -p0
cat ../patches/gcc/4.3.2/55-gcc-4.3.2-atmega32c1.patch | patch -p0
cat ../patches/gcc/4.3.2/56-gcc-4.3.2-atmega32u4.patch | patch -p0
cat ../patches/gcc/4.3.2/57-gcc-4.3.2-attiny167.patch | patch -p0
cat ../patches/gcc/4.3.2/58-gcc-4.3.2-remove-atmega32hvb.patch | patch 
-p0
cat ../patches/gcc/4.3.2/59-gcc-4.3.2-attiny13a.patch | patch -p0
cat ../patches/gcc/4.3.2/60-gcc-4.3.2-atmega32u6.patch | patch -p0
# finally some more patching required, one hunk will fail (missing xmega 
patch)
cat ../patches/gcc/4.3.2/61-gcc-4.3.2-osmain.patch | patch -p0
# so we have a small patch correcting this problem...
cat ../99-gcc-4.3.x-osmain-noxmega.patch | patch -p0
# ada not installed (would fail)
# --> cat ../patches/gcc/4.3.2/70-gcc-4.3.2-ada-mlib.patch | patch -p0
# --> cat ../patches/gcc/4.3.2/71-gcc-4.3.2-ada-freestanding.patch | 
patch -p0
# --> cat ../patches/gcc/4.3.2/72-gcc-4.3.2-ada-timebase.patch | patch 
-p0
# --> cat ../patches/gcc/4.3.2/73-gcc-4.3.2-ada-gnat1_print_path.patch | 
patch -p0
# --> cat ../patches/gcc/4.3.2/74-gcc-4.3.2-ada-optim_static_addr.patch 
| patch -p0
cat ../patches/gcc/4.3.2/75-gcc-4.3.2-builtins_v6.patch | patch -p0

# make definitely fails when build is done in src root directory
# (gives an make error that it does not know how to build 
"libgcc.mvars")
# so build it in separate obj directory (as it is recommended).
cd ..
mkdir gcc_obj
cd gcc_obj
# with the libssp patch we dont need to explicitely disable this lib 
anymore
../gcc-4.3.3/configure --prefix=/usr/local/avr --target=avr 
--program-prefix="avr-" --enable-languages=c
make
# not very exhaustive, but would need autogen. So leave it out and trust 
in god :-)
# make check
make install
cd ..
\rm -rf gcc_obj gcc-4.3.3

# get/build GDB (nothing to patch)
# ================================

wget ftp://ftp.gnu.org/gnu/gdb/gdb-6.8.tar.bz2
tar xvjf gdb-6.8.tar.bz2
#obj in src dir not well supported (causes make error)
mkdir gdb_obj
cd gdb_obj
../gdb-6.8/configure --prefix=/usr/local/avr --target=avr 
--program-prefix="avr-"
make
# check does not work
# --> make check
make install
cd ..
\rm -rf gdb_obj gdb-6.8

# simulavr comes later !

# keep basic binutils/gcc/gdb setup just in case...
# =================================================
tar cvjf usr_local_avr_step1.tar.bz2 /usr/local/avr

#======================================================================= 
=======

# now we compile the libc for AVR (automake should not be needed)
#================================================================

wget 
http://www.very-clever.com/download/nongnu/avr-lib...
tar xvjf avr-libc-1.6.6.tar.bz2
cd avr-libc-1.6.6
# do some necessary patches
cat ../patches/avr-libc/1.6.4/30-avr-libc-1.6.4-dwarf2.patch |patch -p0
cat ../patches/avr-libc/1.6.4/31-avr-libc-1.6.4-builtins.patch |patch 
-p0
# this patch seems to be already applied in 1.6.6, so omit it
# --> cat 
../patches/avr-libc/1.6.4/40-avr-libc-1.6.4-fix-attiny13a-arch.patch 
|patch -p0
./configure --prefix=/usr/local/avr --build=`./config.guess` --host=avr
make
# this is useless...
# --> make check
make install
cd ..
\rm -rf avr-libc-1.6.6

# keep basic binutils/gcc/gdb/libc setup just in case...
# ======================================================
tar cvjf usr_local_avr_step2.tar.bz2 /usr/local/avr

#======================================================================= 
=======

# get/patch and build AVR simulator
# =================================

# simulavr needs installed avr-libc environment
wget 
http://www.very-clever.com/download/nongnu/simulav...
tar xvzf simulavr-0.1.2.6.tar.gz
cd simulavr-0.1.2.6
# patches are quite "old", but seem still not included in 0.1.2.6...
# ok, only the latter may have some impact (initializes some memory)
cat ../patches/simulavr/0.1.2.2/20-simulavr-0.1.2.2-configure.patch 
|patch -p0
cat 
../patches/simulavr/0.1.2.2/41-simulavr-0.1.2.2-fix-reserved-garbage.pat 
ch  |patch -p0
./configure --prefix=/usr/local/avr 
--with-avr-includes=/usr/local/avr/avr/include/
make
# this check looks useful :-)
make check
make install
cd ..
\rm -rf simulavr-0.1.2.6

# finally, get/build avrdude
# ==========================

# 5.6 fails at build, so we stay with 5.5
wget 
http://www.very-clever.com/download/nongnu/avrdude...
tar xvfz avrdude-5.5.tar.gz
cd avrdude-5.5
./bootstrap
./configure --prefix=/usr/local/avr
make
# does nothing
# --> make check
make install
cd ..
\rm -rf avrdude-5.5

# keep complete directory created
# ===============================
tar cvjf usr_local_avr_complete.tar.bz2 /usr/local/avr

# finalize setup, prevent modifications
# =====================================
sudo chmod -R a-w /usr/local/avr

Autor: Bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die toolchain from FemtoOS 4.3.3 m- WinAVR patches

http://www.avrfreaks.net/index.php?name=PNphpBB2&f...


Oder die 4.2.2 toolchain , based on Jörg's FreeBSD patches

http://www.avrfreaks.net/index.php?name=PNphpBB2&f...

mfg
Bingo

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.