mikrocontroller.net

Forum: Compiler & IDEs Windows-Build von avr-gcc 4.5.0


Autor: Lars R. (larsr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Da in dem anderen Thema Anfragen kamen, wie man avr-gcc unter Windows 
selbst kompiliert und ich auch zwei E-Mails zu diesem Thema empfangen 
habe, möchte ich einen Link bereitstellen, der den Zugang zu einem 
Windows-Build von avr-gcc 4.5.0 ermöglicht.

Benutzung auf eigene Gefahr, ich kann nicht dafür garantieren, dass 
fehlerfreier Code erzeugt wird.

Ich hoffe, dass dies mit den Nutzungsbedingungen dieses Forums vereinbar 
ist, jedenfalls konnte ich nichts finden, was dagegen spräche.

http://87.106.84.105/avr-gcc_4.5.0_lto-support_201...

Anwender, die ein installiertes WinAVR auf dem Rechner haben, können 
dessen Dateien einfach mit denen des Archivs überschreiben.

Sollte es doch Einwände geben, so kann dieser Beitrag ja einfach von 
einem Moderator gelöscht werden...

viele Grüße,

Lars

Autor: jw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Lars,
super, probier ich sobald möglich aus.
Gruß,
Jürgen

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmmm...

Bei mir fliegt das mit eineim internal compiler error raus noch bevor er 
mit dem Erstellen der .i-Datei fertig ist. Allerdings nicht bei allen 
Dateien...
Configured with: ../configure --prefix=E:/avr-gcc2 --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --with-dwarf2 --enable-lto --with-libelf-include=E:/MinGW/include/libelf
Thread model: single
gcc version 4.5.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-mmcu=atmega168' '-S' '-save-temps' '-fverbose-asm' '-dp' '-W' '-Wall' '-Wstrict-prototypes' '-Wsign-compare' '-Wextra' '-Wredundant-decls' '-Winline' '-fpack-struct' '-fno-reorder-functions' '-fno-builtin' '-Os' '-std=gnu99' '-fno-keep-inline-functions' '-DF_CPU=24000000' '-DIRQS=48000' '-DRC5CYC=(2*F_CPU/IRQS)' '-URC5_OWN_TIMER' '-UUSE_SERPA' '-DPANIC=0' '-Dmemset=__builtin_memset' '-DVF_LOOKUP_START=0x21' '-DVF_LOOKUP_END=127' '-DVF_EXTRA_GLYPHS=snake_glyph' '-DVEKFONT=(-1) & ~VF_ALWAYS_PROPORTIONAL' '-DBAUDRATE=40000' '-DUART_WAIT_OUTFIFO' '-UFIFO2' '-I../include' '-fno-common' '-ffixed-2' '-ffixed-3' '-ffixed-4' '-ffixed-5' '-ffixed-6' '-ffixed-7' '-ffixed-8' '-fno-tree-scev-cprop' '-fno-inline-small-functions' '-fno-move-loop-invariants' '-fno-tree-loop-optimize' '-fno-split-wide-types' '-mint8'
 e:/winavr-4.5.0/bin/../libexec/gcc/avr/4.5.0/cc1.exe -E -quiet -v -I../include -imultilib avr5 -iprefix e:\winavr-4.5.0\bin\../lib/gcc/avr/4.5.0/ -DF_CPU=24000000 -DIRQS=48000 -DRC5CYC=(2*F_CPU/IRQS) -URC5_OWN_TIMER -UUSE_SERPA -DPANIC=0 -Dmemset=__builtin_memset -DVF_LOOKUP_START=0x21 -DVF_LOOKUP_END=127 -DVF_EXTRA_GLYPHS=snake_glyph -DVEKFONT=(-1) & ~VF_ALWAYS_PROPORTIONAL -DBAUDRATE=40000 -DUART_WAIT_OUTFIFO -UFIFO2 text.c -mmcu=atmega168 -mint8 -std=gnu99 -W -Wall -Wstrict-prototypes -Wsign-compare -Wextra -Wredundant-decls -Winline -fverbose-asm -fpack-struct -fno-reorder-functions -fno-builtin -fno-keep-inline-functions -fno-common -ffixed-2 -ffixed-3 -ffixed-4 -ffixed-5 -ffixed-6 -ffixed-7 -ffixed-8 -fno-tree-scev-cprop -fno-inline-small-functions -fno-move-loop-invariants -fno-tree-loop-optimize -fno-split-wide-types -Os -fpch-preprocess -o text.i
ignoring nonexistent directory "e:\winavr-4.5.0\bin\../lib/gcc/avr/4.5.0/../../../../avr/sys-include"
ignoring duplicate directory "e:/winavr-4.5.0/lib/gcc/../../lib/gcc/avr/4.5.0/include"
ignoring duplicate directory "e:/winavr-4.5.0/lib/gcc/../../lib/gcc/avr/4.5.0/include-fixed"
ignoring nonexistent directory "e:/winavr-4.5.0/lib/gcc/../../lib/gcc/avr/4.5.0/../../../../avr/sys-include"
ignoring duplicate directory "e:/winavr-4.5.0/lib/gcc/../../lib/gcc/avr/4.5.0/../../../../avr/include"
#include "..." search starts here:
#include <...> search starts here:
 ../include
 e:\winavr-4.5.0\bin\../lib/gcc/avr/4.5.0/include
 e:\winavr-4.5.0\bin\../lib/gcc/avr/4.5.0/include-fixed
 e:\winavr-4.5.0\bin\../lib/gcc/avr/4.5.0/../../../../avr/include
End of search list.
<built-in>:0:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [XXX] Error 1

Er schreibt eine Zeile von text.i und ist weg
# 1 "text.c"

Autor: Lars R. (larsr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> hmmm...
>
> Bei mir fliegt das mit eineim internal compiler error raus noch bevor er
> mit dem Erstellen der .i-Datei fertig ist. Allerdings nicht bei allen
> Dateien...

Ich habe ja dazu geschrieben, dass ich keine Gewähr dafür übernehmen 
kann, ob es funktioniert bzw. ob dabei korrekter Code herauskommt.

Bei mir ist der Compiler jedoch noch nicht abgestürzt.

Eventuell gibt es ein Problem mit den verschiedenen Flags.

Ich habe im aktuellen Projekt:

Compiler:
-Wall -gdwarf-2 -std=gnu99 -pedantic -mcall-prologues -Wextra -Wparentheses -Wno-unused-parameter -Wlogical-op -flto -fwhole-program -DF_CPU=14745600UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums

Linker;
-Wl,--relax -Os -flto -fwhole-program -Wl,../bootloader.elf

Damit hatte ich bislang keine Probleme. Und ich habe bislang auch noch 
keinen Grund entdeckt, wieso ich wieder eine ältere Version verwenden 
sollte. Aber das kommt ja auch ein bisschen auf den jeweiligen 
Einzelfall an und ob man bereit ist, herum zu experimentieren.

Autor: Martin e. C. (eduardo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe es probiert und kein Problem gehabt! allerdings ist der Code 
ein bisschen großer

Autor: Johann L. (gjlayde) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
avr-gcc-4.5.0 -mmcu=atmega168 -S foo.c -Os -fno-builtin -mint8

führt zum Absturz während
avr-gcc-4.5.0 -mmcu=atmega168 -S foo.c -Os -fno-builtin

durchläuft. Wenn es bei dir auch abrauscht schliess ich mal 
Build-Probleme aus und das er abschmiert weil ich ein anderes OS 
verwende (W2K SP4).

Einsetzen wollte ich den 4.5.0 nicht, lediglich rumspielen und mal 
schauen ob gcc 4.x inzwischen vielleicht besseren Code macht als 3.4.6 
(in meinem aktuellen Prokejt ist 4.3.3 noch 3.6% größer als 3.4.6. Die 
Größe wäre noch halbwegs erträglich, aber das Zeug ist auch langsamer 
zudem).

Autor: Lars R. (larsr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
>
> avr-gcc-4.5.0 -mmcu=atmega168 -S foo.c -Os -fno-builtin -mint8
> 
>
> führt zum Absturz während
>
>
> avr-gcc-4.5.0 -mmcu=atmega168 -S foo.c -Os -fno-builtin
> 
>
> durchläuft. Wenn es bei dir auch abrauscht schliess ich mal
> Build-Probleme aus und das er abschmiert weil ich ein anderes OS
> verwende (W2K SP4).

Sobald ich -mint8 übergebe ist Feierabend... (Segmentation fault)

Das reicht auch schon, damit Schluss ist:
avr-gcc-4.5.0 foo.c -mint8

Die "-m"-Flags sind sowieso problematisch, diese wirken sich scheinbar 
unmittelbar auf die AVR-Assembler-Erzeugung aus. "-mcall-prologues" ist 
das Einzige, was ich so übergebe.

Da ich dieses Flag, also -mint8, noch nie genutzt habe, ist mir das 
Problem noch gar nicht aufgefallen.

Generell hat sich aber im Vergleich zu avr-gcc-4.3.3 die Schnelligkeit 
des Codes erhöht, empfinde ich jedenfalls subjektiv so, wenn ich mir den 
Assembler anschaue. Es wird zwar manchmal etwas größer, aber durch LTO 
gleicht sich das bei mir wieder mehr als aus.

Ich nutze übrigens Windows XP Professional 32 Bit. Alles was neuer ist, 
kommt mir nicht auf den Mac...

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

Bewertung
0 lesenswert
nicht lesenswert
Vorsicht, Bugs mit -mint8 bitte möglichst nur zusammen mit einem
Patch berichten.  Diese Option steht eigentlich schon lange auf der
Abschussliste, sodass ein nicht aufgelöster Bugreport schnell zum
Anlass genommen werden könnte, sie ganz zu eliminieren.  (Dann ist
der Bug nämlich auch repariert...)

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Vorsicht, Bugs mit -mint8 bitte möglichst nur zusammen mit einem
> Patch berichten.

Und wozu das? Patches werden eh nicht akzeptiert...

> Diese Option steht eigentlich schon lange auf der
> Abschussliste, [...]

Ok, noch einen Grund nicht den 4-er zu verwenden...

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

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Patches werden eh nicht akzeptiert...

Stimmt nicht, allerdings ist das Patch-Handling, hmm, naja, suboptimal.
Man muss den ganzen Kram zwingend in eine Mailingliste posten, obwohl
das Zeug dort eigentlich nur durchrauscht.  Das ist aber die Eintritts-
karte dafür, dass man anschließend jemanden nerven kann, damit man den
Patch auch eingepflegt bekommt...  BTDT.

In diesem Fall hier ist es aber möglicherweise einfacher.  Wenn der
Bug wirklich nur mit -mint8 zusammen hängt, dann ist es rein AVR-
spezifisch, sodass man nur einen der AVR-GCC maintainer (also letztlich
Anatoly Sokolov) davon überzeugen muss, der darf ihn dann selbst
committen.  Ich gehe mal davon aus, dass der Patch auch nur so wenig
umfangreich ist, dass man dafür noch nicht den ganzen Zirkus mit dem
Copyright-Papierkram extra machen muss.  (Hast du denn jemals eine
Antwort von der FSF bekommen, Johann?)

> Ok, noch einen Grund nicht den 4-er zu verwenden...

Vogel-Strauß-Prinzip?

Autor: Martin e. C. (eduardo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin e. C. schrieb:
> Ich habe es probiert und kein Problem gehabt!

einwandfrei läuft doch nicht ganz!

wenn man als MCU ein Xmega eingibt dann ist FINITO!

Output Meldung:

c:\programme\winavr-20100110\bin\../lib/gcc/avr/4.5.0/../../../../avr/in 
clude/avr/io.h:404:6:  warning: #warning "device type not defined"

test2.c: In function 'TCE0_OVF_vect':
test2.c:39:3: error: 'TCNT0' undeclared (first use in this function)
test2.c:39:3: note: each undeclared identifier is reported only once for 
each function it appears in
test2.c:41:20: error: 'PINF' undeclared (first use in this function)

und
.
.
.
.

Autor: Lars R. (larsr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin e. C. schrieb:
> Martin e. C. schrieb:
>> Ich habe es probiert und kein Problem gehabt!
>
> einwandfrei läuft doch nicht ganz!
>
> wenn man als MCU ein Xmega eingibt dann ist FINITO!

Das sieht mir aber mehr danach aus, dass kein passendes Headerfile für 
den Controller vorhanden ist.

Der Compiler selbst ist dabei ja, im Gegensatz zu -mint8, nicht 
abgestürzt.

Autor: Martin e. C. (eduardo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lars R. schrieb:
> Das sieht mir aber mehr danach aus, dass kein passendes Headerfile für
> den Controller vorhanden ist.

doch es gibt oder es gabt, mit dem 4.3.3 war auf alle Fälle ganz ok! 
vielleicht das mit dem:

> Anwender, die ein installiertes WinAVR auf dem Rechner haben, können
> dessen Dateien einfach mit denen des Archivs überschreiben.

ist nicht ganz 100% ok (vermute ich).

Autor: Olaf Dreyer (Firma: O.D.I.S.) (dreyero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe den avr-gcc unter Linux ganz normal übersetzen können, aber die 
avr-libc liess sich damit nicht bauen. Also habe ich die Versuche 
erstmal wieder eingestellt.

Gruß

Olaf

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

Bewertung
0 lesenswert
nicht lesenswert
Martin e. C. schrieb:
> wenn man als MCU ein Xmega eingibt dann ist FINITO!

Weil die Xmega-Patches (aus Gründen, auf die ich hier nicht eingehen
mag) nach wie vor noch nicht im GCC-Tree sind.  Die muss man manuell
drauf patchen.

Autor: Martin e. C. (eduardo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Weil die Xmega-Patches (aus Gründen, auf die ich hier nicht eingehen
> mag) nach wie vor noch nicht im GCC-Tree sind.  Die muss man manuell
> drauf patchen.

ahaa... alles klar!
unter Windows ist bestimmt nicht ganz eifach oder?

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

Bewertung
0 lesenswert
nicht lesenswert
Martin e. C. schrieb:
> unter Windows ist bestimmt nicht ganz eifach oder?

Das Patchen?  Das macht das Kommando "patch", das muss man einfach
nur haben.

Problematischer dürfte es sein, Patches zu finden, die bereits sauber
auf einen GCC 4.5 portiert worden sind.  U. U. leidest du daran, dass
diverse kleinere oder größere Änderungen den Patch nicht mehr 1:1
einpflegbar machen.  Dann ist Handarbeit angesagt, und das ist
letztliche Erics (und die seiner Kollegen) Arbeit beim Herausbringen
eines neuen WinAVR (oder was auch immer dessen Nachfolger wird).

Autor: Martin e. C. (eduardo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, dann lieber es lassen bis die Experte es hinbekommen

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:

> Hast du denn jemals eine Antwort von der FSF bekommen, Johann?

Ich hatte noch ein paarmal nachgefragt und nochmal Adresse ect. 
geschickt um sicher zu gehen, daß alles richtig übermittelt wurde.
Ausser einer Absichtserklärung, mir die Unterlagen zukommen zu lassen, 
ist nichts geschehen.
Irgendwie hat alles einen ziemlich bocklosen Eindruck gemacht, und ich 
bin auch nicht derjenige, der andere abnervt oder anbettelt, um irgendwo 
beitragen zu dürfen...

In der Compiler-Bild gab's neulich einen Beitrag, der sich reger 
Beteiligung erfreute.
   http://gcc.gnu.org/ml/gcc/2010-04/msg00570.html
Offenbar bin ich nicht der einzige, der beim Versuch, die Hürden zu 
überwinden, irgendwann frustriert aufgegeben hat.


Jörg Wunsch schrieb:
>
> Problematischer dürfte es sein, Patches zu finden, die bereits sauber
> auf einen GCC 4.5 portiert worden sind.  U. U. leidest du daran, dass
> diverse kleinere oder größere Änderungen den Patch nicht mehr 1:1
> einpflegbar machen.  Dann ist Handarbeit angesagt, und das ist
> letztliche Erics (und die seiner Kollegen) Arbeit beim Herausbringen
> eines neuen WinAVR (oder was auch immer dessen Nachfolger wird).

Wie ich gesehen habe hat Eric inzwischen ein Assignment, aber dennoch 
gibt es für WinAVR eine riesige Patch-Liste, die auch Patches für gcc 
beinhaltet. Gibt es einen Grund, diese nicht in gcc einzupflegen? Es ist 
ja eine tierische Arbeit, immer alles Zeug zurück- oder vor zu portieren 
bzw. die Patches auf jedes neues Release anzupassen.

Ausserdem wird es so viel schwerer, den Überblick zu behalten, und kein 
avr-Maintainer wird bereitwillig gcc-Patches ins FSF-Repository nehmen, 
weil das zusätzlichen Aufwand für die Nachpflege der "Privat"-Patches 
für die nächste Release bedeuten würde.

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

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

>> Hast du denn jemals eine Antwort von der FSF bekommen, Johann?
>
> Ich hatte noch ein paarmal nachgefragt und nochmal Adresse ect.
> geschickt um sicher zu gehen, daß alles richtig übermittelt wurde.
> Ausser einer Absichtserklärung, mir die Unterlagen zukommen zu lassen,
> ist nichts geschehen.

Schei...

Bei mir hatte das seinerzeit relativ problemlos geklappt, auch
wenn ich das nach wie vor als "Luftnummer" betrachte, insbesondere
natürlich angesichts der Nichtübertragbarkeit der Urheberschaft
gemäß deutschem Urheberrecht:

http://de.wikipedia.org/wiki/Deutsches_Urheberrech...

(die bei den Amis regelmäßig auf komplettes Unverständnis stößt,
da deren Copyright die Urheberschaft mit den Nutzungsrechten daran
vermischt).

> Irgendwie hat alles einen ziemlich bocklosen Eindruck gemacht, und ich
> bin auch nicht derjenige, der andere abnervt oder anbettelt, um irgendwo
> beitragen zu dürfen...

Naja, wenn du Bock hast, überhaupt einen deiner Beiträge (die ich
persönlich für wertvoll finde) durchzuboxen, dann würde ich die
Sache einfach eskalieren lassen: einreichen, nachtreten, und bei
der Frage nach dem copyright assignment stets betonen, dass du es
eingereicht hast, aber die FSF offenbar nicht interessiert ist.

> In der Compiler-Bild gab's neulich einen Beitrag, der sich reger
> Beteiligung erfreute.
>    http://gcc.gnu.org/ml/gcc/2010-04/msg00570.html

Manuel ist mir schon mehr als einmal als sehr hilfreiche Person
aufgefallen.  Wenn ich mich nicht täusche, hat er seinerzeit den
0b-Patch auch mit voran getrieben.

> Offenbar bin ich nicht der einzige, der beim Versuch, die Hürden zu
> überwinden, irgendwann frustriert aufgegeben hat.

Wobei andere offensichtlich noch schlimmere Hürden zu nehmen haben:
die Amis müssen sich noch einen Disclaimer ihres Brötchengebers
einholen.  Davon sind wir zum Glück verschont.  Auf Dinge, die du
in deiner Freizeit machst hat (sofern du damit nicht gegen deine
dienstlichen Geheimhaltungspflichten verstößt, d. h. keine Dienst-
geheimnisse preisgibst) dein Brötchengeber hier keinerlei Anspruch.
Ein anderer Aspekt, in dem sich das deutsche Urheberrecht vom
US-Copyright unterscheidet.

> Wie ich gesehen habe hat Eric inzwischen ein Assignment, aber dennoch
> gibt es für WinAVR eine riesige Patch-Liste, die auch Patches für gcc
> beinhaltet. Gibt es einen Grund, diese nicht in gcc einzupflegen?

Ich denke, dass gerade bei den Xmegas der Grund einfach Zeitmangel
ist, das so weit aufzubereiten, dass Anatoly es einpflegen kann.
Die meisten anderen Patches, die GCC-seitig bei WinAVR herumlungern,
sind ja Sachen, die im SVN bereits korrigiert sind, die er aber auf
die jeweils bei WinAVR gelieferte ältere Compilerversion rückportiert
haben möchte.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:

> Auf Dinge, die du
> in deiner Freizeit machst hat (sofern du damit nicht gegen deine
> dienstlichen Geheimhaltungspflichten verstößt, d. h. keine Dienst-
> geheimnisse preisgibst) dein Brötchengeber hier keinerlei Anspruch.

Das könnte sich aber mit der jüngsten BGH Entscheidung zur Zulässigkeit 
von Softwarepatenten und dem bestehenden Gesetz über 
Arbeitnehmererfindungen (§18 und §19) ändern.

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

Bewertung
0 lesenswert
nicht lesenswert
Stefan B. schrieb:

> Das könnte sich aber mit der jüngsten BGH Entscheidung zur Zulässigkeit
> von Softwarepatenten und dem bestehenden Gesetz über
> Arbeitnehmererfindungen (§18 und §19) ändern.

Jein.  Die möglichen Grenzen für Softwarepatente sind relativ eng,
die Software muss ein technisches Problem lösen, das vergleichbar
anderweitig mit "herkömmlicher Technik" gelöst worden wäre.  Der
Wikipedia-Artikel zu Softwarepatenten geht recht ausführlich darauf
ein.  Es ist nicht einfach jedes x-beliebige Stück Software
patentierbar.

Außerdem müsste im Zweifelsfalle der Brötchengeber hier als Kläger
auftreten, dafür muss er dann den Nachweis erbringen, dass die
strittige Softwarelösung patentreif gewesen wäre, also einerseits
die rechtlichen Patentvoraussetzungen erfüllt, andererseits die
Voraussetzung, dass bis dato keine vergleichbare Lösung veröffentlicht
worden war.  Gerade letzteres dürfte für das Themengebiet, das wir
hier im Blick haben (Compilertechnologie) außerordentlich schwierig
werden.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir als Rechtslaien fällt es ganz schwer die Auswirkungen verbindlich 
abzuschätzen.

Ich zähle in diesem Fall in guter paranoider Manier 1+1 zusammen und 
verpasse mir ein Eselsohr "aufpassen", weil alte Regeln (Freizeit => 
keinerlei Anspruch...) eventuell ab jetzt nicht mehr gelten. Ob das 
berechtigt ist, wird die Zeit zeigen.

Der "Ami" bannt durch den Disclaimer grundsätzlich die Gefahr, dass ihn 
sein AG deswegen vor Gericht zerrt. Unsere Schonung ist vielleicht nur 
ein Scheinvorteil.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was haben denn Arbeitnehmererfindungen mit den Hobby-Ergebnissen der 
Freizeit zu tun, die weder innerhalb der Arbeitszeit noch unter Nutzung 
irgendwelcher Arbeitgeber-Infrastruktur zustandegekommen sind und auch 
keine Betriebsgeheimnisse berühren?

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.