Hallo Forum, als ich heute mal auf der Seite der avr-libc war fiel mir die Versionsnummer ins Auge: 2.0.0: http://www.nongnu.org/avr-libc/user-manual/ Davor war 1.8.1 wenn ich mich nicht irre. Zu diesem "Ereignis" 2 Fragen: 1. Gibt es ein Changelog, was bei diesem wirklichen 'Sprung der Versionsnummer erklärt? Ich habe auf meiner kurzen Suche nämlich keins gefunden. 2. Lohnt sich ein Update auf die neue Version (zB wegen Bugfixes)? mfG N.G. PS: Gibt es eine Möglichkeit die libc zu Unterstützen? Ich würde mich einerseits gerne an dem Projekt beteiligen, jedoch fehlt mir persönlich nur noch der double-Support (64bit). Es gbt auch 2 offene "Stellen", jedoch trifft keine der beiden Beschreibungen auf mich zu.
N. G. schrieb: > 1. Gibt es ein Changelog, was bei diesem wirklichen 'Sprung der > Versionsnummer erklärt? Ich habe auf meiner kurzen Suche nämlich keins > gefunden. Am ehesten wird das klar, wenn du eine avr-gcc v5.2+ Installation mit einer 4.9 oder älter vergleichst (5.0 und 5.1 sind nicht funktional): v5 unterstützt keine Devices mehr; der Device-Support läuft über die Abbildung von -mmcu= auf Device-spezifische Specs in
1 | lib/gcc/avr/$version/device-specs |
Es gibt Device-Libs in
1 | avr/lib/$multidir |
welche Device-abhängige (und damit nicht-Standard) Funktionen enthalten wie die für den EEPROM-Zugriff. Die Namenskonvention für Startup-Objekte haben sich geändert, z.B. von crtm8.o zu crtatmega8.o, d.h. der crt-Name leitet sich direkt aus -mmcu= ab. > 2. Lohnt sich ein Update auf die neue Version (zB wegen Bugfixes)? Die Version muss zum avr-gcc passen, siehe die GCC 5 Release Caveats, d.h. mit v5.2+ brauch man avr-libc 2+ oder eine entsprechende Entwicklungsversion von 1.8.1 SVN trunk. Umgekehrt müsste die neuere avr-libc auch auf alte avr-gccs passen, was per avr-libc configure erkannt wird. > jedoch fehlt mir persönlich nur noch der double-Support (64bit). Das wäre ein echt dicker Brocken und kein dünnes Brett zu bohren. Nicht zuletzt will man dann auch double-support im avr-gcc haben, was momentan nicht der Fall ist (und nein, es genügt nicht, ein Makro umzudefinieren). Jörg machte mal den Vorschlag, double per 48 Bit zu implementieren; wieviel Ärger das im GCC macht kann ich nur schlecht abschätzen.
:
Bearbeitet durch User
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.