Forum: Compiler & IDEs Unterschiedliche Typen der nach dem Compilerlauf erzeugten Programmdateien von gcc und clang


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Klaus F. (klausfuchs)


Lesenswert?

In Debian (V.10) erzeugt jeder Comilerlauf von gcc regelmässig 
ausführende Dateien (Programme) mit der Typenbezeichnung bzw. 
-beschreibung "Gemeinsame Bibliothek", womit sich allerdings das Problem 
verbindet, dass ein Anklicken der betreffenden Datei trotz sämtlich 
erteilter Ausführungsrechte nicht zum Start im Dateimanager führt. 
Hingegen liess sich noch vor Jahren mit gcc und gleichem C-Code direkt 
ausführende Dateien mit der Typenbezeichnung bzw. -beschreibung 
"Programm" generieren, deren Start selbstverständlich direkt im 
Dateimanager durch Anklicken gelang und zwar auf gleiche Weise wie es 
sich jetzt noch mit dem C-Compiler clang unter Debian vollziehen lässt.

Davon unabhängig lassen sich im Terminal alle vorgeannten Resultate mit 
./cprogramm starten, aber vielfach bedarf es in meinen Anwendungsfällen 
des explizit direkten Programmstartes über den jeweiligen Dateimanager.

Von daher freue ich mich um so mehr über Eure Feedbacks und Erklärungen 
bzw. ggf. Abhilfemöglichkeiten des vorgeschilderten Problems.

: Bearbeitet durch User
von Foobar (asdfasd)


Lesenswert?

"Gemeinsame Bibliothek" soll wohl ein "shared library" sein (übliche 
Endung .so, aber nicht zwingend).  Damit der Compiler die erzeugt, musst 
du die Option "-shared" angegeben haben.  Warum machst du das, wenn du 
sie garnicht haben willst.

von Klaus F. (klausfuchs)


Lesenswert?

Danke für Deine rasche Antwort. Bedauerlicherweise erzeugt gcc seit 
einigen Jahren automatisch ohne Eingaber der Option "-shared" das 
Dateiformat "Gemeinsame Bibliothek" bzw. "shared library" und ich vermag 
es auch durch keine mir bekannte Option abzustellen.

von Oliver S. (oliverso)


Lesenswert?

Dann zeig doch mal, wie du den gcc aufrufst.

Oliver

von Foobar (asdfasd)


Lesenswert?

> Bedauerlicherweise erzeugt gcc seit einigen Jahren automatisch ohne
> Eingaber der Option "-shared" das Dateiformat "Gemeinsame Bibliothek"
> bzw. "shared library"

Der gcc von Hause aus mit Sicherheit nicht.  Das muss irgendeine kaputte 
Einstellung bei dir sein.

> und ich vermag es auch durch keine mir bekannte Option abzustellen.

Weil das Erstellen von Executables der Default ist.  Afaik gibt es keine 
Option, ein vorhandes "-shared" rückgängig zu machen.

Zeig mal deine Kommandozeile, mit der du Übersetzt.

von Klaus F. (klausfuchs)


Lesenswert?

Gerne:

$ gcc -Wall -o Programmname Code.c -lm

wobei die damit entstehende ausführende Datei "Programmname" die 
Typenbezeichnung bzw. -beschreibung "Gemeinsame Bibliothek" trägt im 
Gegensatz zum Aufruf

$ clang -Wall -o Programmname Code.c -lm

und hieraus die ausführende Datei "Programmname" mit der 
Typenbezeichnung bzw. -beschreibung "Programm" resultiert, die sich im 
Dateimanager starten lässt, so wie vor Jahren auch mit gcc.

: Bearbeitet durch User
von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

Klaus F. schrieb:
> Option "-shared" das
> Dateiformat "Gemeinsame Bibliothek" bzw. "shared library" und ich vermag
> es auch durch keine mir bekannte Option abzustellen.

Das Gegenstück müsste eigentlich "-static" sein:
- https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

von Klaus F. (klausfuchs)


Lesenswert?

Vielen Dank für Deinen wie auch Eure Hinweise auf dem Weg zum Ziel.

In der Tat es funktioniert beispielsweise mit folgender Sequenz:

$ gcc -Wall -o Programmname Code.c -lm -static

Daraus resultiert die ausführende Datei "Programmname" mit der
Typenbezeichnung bzw. -beschreibung "Programm", die sich tatsächlich im
Dateimanager starten lässt.

Habt Tausenddank :-)

: Bearbeitet durch User
von Klaus F. (klausfuchs)


Lesenswert?

Weiss vielleicht jemand noch etwas in diesem Zusammenhang zur Situation 
um den Compiler clang im Vergleich zu gcc mit der Option "-static" zu 
berichten, da clang ja von vornherein ausführende Dateien mit der 
Typenbezeichnung bzw. -beschreibung "Programm" erzeugt, die sich durch 
Anklicken im Dateimanager direkt starten lassen.

: Bearbeitet durch User
von Bauform B. (bauformb)


Lesenswert?

Schau mal nach, wie groß die Programmname jeweils sind. Normalerweise 
will man -static nicht, weil die Programme riesig werden. Was sagt "file 
Programmname" zu den drei Varianten?

von Klaus F. (klausfuchs)


Lesenswert?

1.)
$ gcc -Wall -o Programmname Code.c -lm
-> Programmname, Gemeinsame Bibliothek, 34 KiB
$ file Programmname
Programmname: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 3.2.0, BuildID[sha1]=0bb952650699494343de6ea24ada11ba4d15f5f8, 
not stripped

2.)
$ gcc -Wall -o Programmname Code.c -lm -static
-> Programmname, Programm, 1.4 MiB
$ file Programmname
Programmname: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), 
statically linked, for GNU/Linux 3.2.0, 
BuildID[sha1]=8b4f050b4dcb3721811014afbf1bc5878b76fbd8, not stripped

3.)
$ clang -Wall -o Programmname Code.c -lm
-> Programmname, Programm, 33.9 KiB
$ file Programmname
Programmname: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 3.2.0, BuildID[sha1]=afbc0cb5f3765982b4131181d679f947cff123f7, 
not stripped

von Bauform B. (bauformb)


Lesenswert?

Probier mal -no-pie statt -static. Aber das kann nur eine Notlösung 
sein. Der Dateimanager müsste lernen, dass neuerdings auch solche 
Dateien ausführbar sind.

von Klaus F. (klausfuchs)


Lesenswert?

Vielen Dank für Deinen ausgezeichnenten Tipp.

Bereits vorgestern probierte ich mit dieser Option, also -no-pie, zu 
arbeiten leider erfolglos, da ich sie möglicherweise an der falschen 
Stelle platzierte anstatt sie hinten anzufügen.

Nunmehr funktioniert es, wie folgende Zeilen zeigen:

$ gcc -Wall -o Programmname Code.c -lm -no-pie
-> Programmname, Programm, 33.8 KiB
$ file Programmname
Programmname: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 3.2.0, BuildID[sha1]=ec9be72848e9f3c570ff22e7f984b0e3ec5b80ce, 
not stripped

Jetzt dürften also die Ergebnisse von "clang" und "gcc zusammen mit 
-no-pie" identisch sein, oder?

: Bearbeitet durch User
von Oliver S. (oliverso)


Lesenswert?

Klaus F. schrieb:
> 1.)
> $ gcc -Wall -o Programmname Code.c -lm
> -> Programmname, Gemeinsame Bibliothek, 34 KiB
> $ file Programmname

Wer oder was zeigte denn das -> "Programmname, Gemeinsame Bibliothek, 34 
KiB" an?

> Programmname: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
> GNU/Linux 3.2.0, BuildID[sha1]=0bb952650699494343de6ea24ada11ba4d15f5f8,
> not stripped

Und wo ist jetzt das Problem?

Oliver

von Markus F. (mfro)


Lesenswert?

Debian 10 hat zwar noch LTS Support bis Mitte nächstes Jahr, ist aber 
trotzdem nicht besonders aktuell. Deswegen hat es Schwierigkeiten, PIE 
Executables von Shared Libraries zu unterscheiden und der Gnome 
Dateimanager Nautilus weigert sich, letztere zu starten (tatsächlich 
sind die Gnome-Designer sogar der Ansicht, ein Dateimanager solle 
überhaupt keine Executables starten und haben sich deswegen lange 
geweigert, das überhaupt als Fehler anzuerkennen).

Falls das noch die Original 10.0-Installation von Debian ist, hilft evt. 
ein Upgrade auf 10.13 (die letzte Debian 10). Ich weiss es nicht, aber 
es könnte sein, dass da was repariert ist.

von Klaus F. (klausfuchs)



Lesenswert?

Anknüpfend an die dankenswerten jüngsten Ausführungen von Oliver und 
Markus sei auf die angehängten Screenshots verwiesen.

-> "Programmname, Gemeinsame Bibliothek, 34 KiB" steht für die 
entsprechenden im LXDE-Dateimanager, pcmanfm, ersichtlichen Angaben.

Möglicherweise liegt das Problem nicht nur bei Gnome, sondern 
möglicherweise noch tiefer im System, da auch LXDE davon betroffen zu 
sein scheint?

von Harald K. (kirnbichler)


Lesenswert?

Könntest Du statt der nichtssagenden Bezeichnungen irgendwelcher 
Dateimanager nicht einfach die Ausgabe von
1
ls -al

posten?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Klaus F. schrieb:
> Möglicherweise liegt das Problem nicht nur bei Gnome, sondern
> möglicherweise noch tiefer im System, da auch LXDE davon betroffen zu
> sein scheint?

Das Problem liegt in den Dateimanagern selbst.

Die Dateien sind ja ordnungsgemäß ausführbar: wenn du auf die 
Kommandozeile gehst, kannst du sie mit
1
./Programmname

starten. GCC baut halt mittlerweile standardmäßig ein "position 
independant executable" (PIE), und die Dateimanager begreifen nicht, 
dass selbiges tatsächlich eine ausführbare Datei ist. Die Schuld liegt 
also bei denen.

von Klaus F. (klausfuchs)


Lesenswert?

Noch zur Frage von Harald:

ls -al bringt leider nicht viel, wie die folgende Ausgabe verdeutlicht:
1
$ ls -al
2
insgesamt 2
3
-rw-r--r-- 1 21627 Mai  3  2012 Code.c
4
-rwxr-xr-x 1 34840 Apr 19 16:31 Programmname

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Jörg W. schrieb:
> Das Problem liegt in den Dateimanagern selbst.

Möglicherweise auch an der Datenbank von "file". Wenn ich das gleiche 
unter FreeBSD mache und ein PIE erzeuge, sagt mir file:
1
% file Programmname
2
Programmname: ELF 64-bit LSB pie executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.3 (1203505), FreeBSD-style, with debug_info, not stripped

d.h. da steht eindeutig "executable" statt nur "shared object" unter 
Linux:
1
$ file Programmname
2
Programmname: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=3ae102fd1ede886ab7595a2d8d41ee37d3cf8719, for GNU/Linux 3.2.0, not stripped

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

(Wobei ich bei dir auch "pie executable" sehe, also doch die 
Dateimanager.)

von Klaus F. (klausfuchs)


Lesenswert?

Worin könnten mögliche Nachteile bestehen bei Verwendung von

$ gcc -Wall -o Programmname Code.c -lm -no-pie

anstatt

$ gcc -Wall -o Programmname Code.c -lm

und weshalb greift clang offensichtlich nicht auf pie zurück?

von Daniel A. (daniel-a)


Lesenswert?

Im Grunde ist es ganz simple. Hat die Datei das Executable Flag gesetzt, 
ist sie ausführbar. Der Dateimanager sollte dann beim anklicken das Ding 
ausführen, oder nachfragen. Der Dateityp ist da völlig egal. Wenn dein 
Dateimanager das nicht tut, dann schmeiss ihn weg, und nimm einen 
anderen. Thunar, dolphin, pcmanfm, nautilus, ... Gibt ja viel Auswahl.

von Klaus F. (klausfuchs)


Lesenswert?

Bei mir kommt pcmanfm zum Einsatz. Von daher sollte der Startklick 
eigentlich funktionieren.

von Oliver S. (oliverso)


Lesenswert?

Jörg W. schrieb:
> d.h. da steht eindeutig "executable" statt nur "shared object" unter

Lt dem hier:

Beitrag "Re: Unterschiedliche Typen der nach dem Compilerlauf erzeugten Programmdateien von gcc und clang"


steht bei TO da auch executable, nur der grafische Dateimanager ist 
anderer Meinung.

Oliver

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Klaus F. schrieb:
> weshalb greift clang offensichtlich nicht auf pie zurück?

GCC bei mir (FreeBSD) macht es auch nicht von sich aus.

Keine Ahnung, warum dem Linux-GCC das jemand als Default beigebogen hat. 
Da müsstest du diejenigen fragen, die diese Entscheidung getroffen haben 
…

Abhandlungen dazu kannst du dir ergoogeln, hier bspw.:

https://docs.oracle.com/cd/E26505_01/html/E26506/glmqp.html

von Daniel A. (daniel-a)


Angehängte Dateien:

Lesenswert?

Merkwürdig, bei mir fragt pcmanfm brav nach... (und erkennt es auch als 
executable)

: Bearbeitet durch User
von Klaus F. (klausfuchs)


Lesenswert?

Vielen Dank Jörg für Deine überaus hilfreichen wie klärenden Beiträge in 
der Sache sowie natürlich auch allen anderen Teilnehmern.

Basierend darauf seien der Übersicht willen an dieser Stelle nochmals 
die bis hierher wohl wesentlichen diesem Thread zugrundeliegenden 
Befehlsvarianten bzw. -welten in der mir von 1.) nach 4.) aufsteigend 
bevorzugten Reihenfolge aus Gründen der Start- und Ausführbedingungen 
und darüber hinausgehenden Kriterien wie beispielsweise 
Speicherplatzbedarf, wonach 2.) eigentlich vollkommen ausscheidet, 
angegeben:

1.)
$ gcc -Wall -o Programmname Code.c -lm
-> Angaben im Dateimanger pcmanfm: Programmname, Gemeinsame Bibliothek, 
34 KiB
$ file Programmname
Programmname: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 3.2.0, BuildID[sha1]=0bb952650699494343de6ea24ada11ba4d15f5f8,
not stripped

2.)
$ gcc -Wall -o Programmname Code.c -lm -static
-> Angaben im Dateimanger pcmanfm: Programmname, Programm, 1.4 MiB
$ file Programmname
Programmname: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux),
statically linked, for GNU/Linux 3.2.0,
BuildID[sha1]=8b4f050b4dcb3721811014afbf1bc5878b76fbd8, not stripped

3.)
$ gcc -Wall -o Programmname Code.c -lm -no-pie
-> Angaben im Dateimanger pcmanfm: Programmname, Programm, 33.8 KiB
$ file Programmname
Programmname: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 3.2.0, BuildID[sha1]=ec9be72848e9f3c570ff22e7f984b0e3ec5b80ce,
not stripped

4.)
$ clang -Wall -o Programmname Code.c -lm
-> Angaben im Dateimanger pcmanfm: Programmname, Programm, 33.9 KiB
$ file Programmname
Programmname: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 3.2.0, BuildID[sha1]=afbc0cb5f3765982b4131181d679f947cff123f7,
not stripped

Auffällig bleibt insbesondere die Gemeinsamkeit der Ausgaben von 3.) und 
4.), die immer in "speichersparenden" und "aus dem Dateimanager 
startbaren" Programmen münden, was sich für bestimmte Anwendungsfälle 
als unverzichtbar erweist, speziell wenn es darum geht, dem Endanwender 
ein direkt mittels der grafischen Benutzerschnittstelle anwählbares 
Programm zur Verfügung zu stellen und der Endanwender sich nicht 
zugleich mit Programmaufrufen aus dem Terminal heraus aufhalten oder 
beschäftigen möchte bzw. will.

: Bearbeitet durch User
Beitrag #7398013 wurde vom Autor gelöscht.
Beitrag #7398022 wurde vom Autor gelöscht.
von Klaus F. (klausfuchs)


Lesenswert?

Daniel darf ich Dich höflich nach Deiner Distributuion fragen? Ggf. 
starten die mit gcc generierten Programme durch Anklicken im 
Dateimanager unter Ubuntu aber nicht unter Debian.

von Daniel A. (daniel-a)


Lesenswert?

Ich nutze Devuan (release daedalus). Die entsprechenden Pakete sind 
eigentlich die selben, wie in Debian Bookworm.
1
$ lsb_release -a
2
No LSB modules are available.
3
Distributor ID:  Devuan
4
Description:  Devuan GNU/Linux 5 (daedalus/ceres)
5
Release:  5
6
Codename:  daedalus ceres
7
$ dpkg-query -l | grep ' gcc \|pcmanfm'
8
ii  gcc                                           4:12.2.0-3                            amd64        GNU C compiler
9
ii  pcmanfm                                       1.3.2-1                               amd64        extremely fast and lightweight file manager

Sollte zwar eigentlich nicht daran liegen.

von Martin H. (horo)


Lesenswert?

Klaus F. schrieb:
> Anklicken der betreffenden Datei trotz sämtlich
> erteilter Ausführungsrechte nicht zum Start im Dateimanager führt

Im aktuellen Debian Stable funktioniert das prima, kommt halt auf den 
Dateimanager an - auf meinem Desktop ist es der mc (im Terminal).

von Foobar (asdfasd)


Lesenswert?

Etwas Hintergrund: Position-Independent-Executables (PIE) werden für 
Address-Space-Layout-Randomization (ASLR) gebraucht.  ASLR ist eine 
Methode, um Exploits das Leben etwas schwerer zu machen, indem das 
Programm bei jedem Start an andere Adressen geladen wird.  Das geht nur, 
wenn dem Programm seine Lage im Speicher egal ist - das macht die 
PIE-Compiler-Option.  PIE braucht etwas mehr Speicher, ist etwas 
langsamer als regulärer Code und muß beim Laden zusätzlich relokiert 
werden.

Debian-Hardened (eine auf Sicherheit optimierte Version von Debian) hat 
PIE vor ein paar Jahren als Default für alle Programme eingeführt.  U.A. 
wurde auch der gcc angepasst, dass er standardmäßig solche Executables 
erstellt. Es scheint, dass das reguläre Debian das igendwann übernommen 
hat.

Ich bin kein Fan von PIE, auf meinen Systemen ist ASLR abgeschaltet.

Das Problem von Klaus ist ausschließlich der Dateimanager, der bei PIEs 
einen falschen Dateityp erkennt und entspr falsche Aktionen assoziiert. 
Der sinnvollste Fix wäre, den Dateimanager zu reparieren. 
Non-PIE-Programme zu erstellen ist ein Work-Around, der allerdings die 
Systemphilosophie unterwandert.  Eine Alternative wäre z.B. ein 
Shell-Script, das der Dateimanager erkennt und welches dann das 
Executable aufruft:
1
#!/bin/sh
2
exec Programmname "$@"  # Programmname ggf mit Pfad

Einige Dateimanager bieten auch kleine App-Links an, mit denen man dem 
Programmen u.a. Icons zuordnen kann aber auch den eigentlichen Aufruf 
hinterlegt.

von Klaus F. (klausfuchs)


Lesenswert?

Vielleicht gibt es ja beispielsweise auf der Basis von
1
$ xdg-mime query filetype ~/pfad/Programmname
2
application/x-sharedlib
3
$ xdg-mime query default application/x-sharedlib

Möglichkeiten, den Dateimanager, wie pcmanfm, zu überlisten bzw. zum 
Start des pie-executables durch Anklicken im Dateimanager zu bewegen?

: Bearbeitet durch User
von Daniel A. (daniel-a)


Lesenswert?

Bei mir sagt das application/x-executable.

Suche mal nach "grep -r application/x-sharedlib /usr/share/mime/". 
Eventuell ist da was das matcht. Bei mir ist das hier drin:
1
dpa@dragonfly:~/x$ grep -r application/x-sharedlib /usr/share/mime/
2
/usr/share/mime/types:application/x-sharedlib
3
grep: /usr/share/mime/magic: binary file matches
4
/usr/share/mime/packages/freedesktop.org.xml:  <mime-type type="application/x-sharedlib">
5
/usr/share/mime/application/x-sharedlib.xml:<mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="application/x-sharedlib">
6
/usr/share/mime/globs:application/x-sharedlib:*.so.[0-9]*
7
/usr/share/mime/globs:application/x-sharedlib:*.so
8
grep: /usr/share/mime/mime.cache: binary file matches
9
/usr/share/mime/globs2:60:application/x-sharedlib:*.so.[0-9]*
10
/usr/share/mime/globs2:50:application/x-sharedlib:*.so
11
dpa@dragonfly:~/x$

Aber selbst dann, ein Dateimanager sollte eigentlich nicht danach 
gehen...

von Klaus F. (klausfuchs)


Lesenswert?

Meine diesbezügliche Ausgabe sieht so aus:

$ grep -r application/x-sharedlib /usr/share/mime/
/usr/share/mime/globs2:50:application/x-sharedlib:*.dll
/usr/share/mime/globs2:50:application/x-sharedlib:*.so.[0-9].*
/usr/share/mime/globs2:50:application/x-sharedlib:*.so
/usr/share/mime/globs2:50:application/x-sharedlib:*.so.[0-9]
Übereinstimmungen in Binärdatei /usr/share/mime/mime.cache
/usr/share/mime/globs:application/x-sharedlib:*.dll
/usr/share/mime/globs:application/x-sharedlib:*.so.[0-9].*
/usr/share/mime/globs:application/x-sharedlib:*.so
/usr/share/mime/globs:application/x-sharedlib:*.so.[0-9]
/usr/share/mime/types:application/x-sharedlib
/usr/share/mime/packages/libfm.xml:  <mime-type 
type="application/x-sharedlib">
/usr/share/mime/packages/freedesktop.org.xml:  <mime-type 
type="application/x-sharedlib">
Übereinstimmungen in Binärdatei /usr/share/mime/magic
/usr/share/mime/application/x-sharedlib.xml:<mime-type 
xmlns="http://www.freedesktop.org/standards/shared-mime-info"; 
type="application/x-sharedlib">

von Daniel A. (daniel-a)


Lesenswert?

Das sieht eigentlich unauffällig aus. Eventuell könnte man noch 
nachsehen, ob unter /usr/local/share/mime oder ~/.local/share/mime/ 
etwas ist.

von Klaus F. (klausfuchs)


Lesenswert?

Sowohl unter ~/.local/share/ als auch /usr/local/share/ findet sich kein 
Verzeichnis /mime.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.