Announcement: there is an English version of this forum on Nach der Installation der neuesten Version kommt bei allen Projekten
eine Fehlermeldung:
avr-gcc (GCC) 4.1.1 (WinAVR 20070101)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
Compiling: wakku.c
avr-gcc -c -mmcu=atmega8 -I. -gstabs -DF_CPU=3686400UL -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=wakku.lst -std=gnu99 -MD -MP -MF
.dep/wakku.o.d wakku.c -o wakku.o
avr-gcc: _spawnv: No such file or directory
make.exe: *** [wakku.o] Error 1
> Process Exit Code: 2
Was tun?
Fu.... jetzt habe ich die alte Version installiert mit dem Erfolg: > "make.exe" all make.exe: *** No rule to make target `all'. Stop. > Process Exit Code: 2 > Time Taken: 00:01 Wie war das: never touch a running system ... Hilfe!
Vielleicht solltest Du das/die Makefile(s) mal anhängen... außerdem könntest Du mal die Pfadangaben überprüfen. Vielleicht wird ja gar nicht das richtige make aufgerufen. Werner
jetzt habe ich im Notepad einen eigenen Befehl definiert: make.exe all mit meinem Pfad als Arbeitsverzeichnis und es geht. Scheint also dass das eingebaute "make all" eine anderen makefile nimmt?? von welchem Pfad holt es denn den makefile, kann ich den einstellen?
jetzt habe ich im Project den makefile rausgeschmissen und wieder neu eingehängt, jetzt gehts. Komisch aber dass ich ja auch vorher im Editor den richtigen makefile hatte. noch ne Info zum ursprünglichen Problem: ich hab noch Win98, wie kann ichs hinbiegen auch mit der neisten WINAVR Version zu arbeiten.
"ich hab noch Win98, wie kann ichs hinbiegen auch mit der neisten WINAVR Version zu arbeiten." Ursache ist wohl ein Fehler im gcc Version 4.1.1 Quellcode. Der Fehler wurde erst nach Veroeffentlichung von 4.1.1 behoben. Betroffene Datei des gcc-Quellcodes: pex-win32 (oder aehnlich, nicht genau in Erinnerung). Korrigierte Versionen im gcc-cvs. Abhilfe: den gcc mit modifzizierter "pex"-Datei selbst compiliert. (Diese Vorgehensweise hat beim arm-elf-gcc in WinARM die Inkompatibilität mit Win9x beseitigt.) Martin Thomas
Martin Thomas wrote: > Ursache ist wohl ein Fehler im gcc Version 4.1.1 Quellcode. Der Fehler > wurde erst nach Veroeffentlichung von 4.1.1 behoben. Betroffene Datei > des gcc-Quellcodes: pex-win32 (oder aehnlich, nicht genau in > Erinnerung). Korrigierte Versionen im gcc-cvs. Kannst du das mal bitte Eric Weddington schreiben? Er hat ja die Version 20070102 eher als eine Art "Releasekandidat" angesehen. Falls er doch noch einmal kurzfristig eine neue Version ausrollt, kann er das ja mit beheben. Andererseits wird der Support für das alte MS-DOS mit dem grafischen Benutzeraufsatz wohl immer schwieriger. Es wäre jedem dringend nahezulegen, davon allmählich mal Abstand zu gewinnen. In avrfreaks.net war auch zu lesen, dass die AVR-Studio-Nutzer zunehmend zu kämpfen haben, weil natürlich MS für seine alten Leichen keine Updates mehr bringt. Da sich aber AVR Studio auf Teile des Windows verlässt wie den XML-Parser, führen die entsprechenden alten Bugs zunehmend auch in diesem Bereich zur Unbenutzbarkeit.
Ich glaube eher dass da alte cygwin DLLs im Pfad liegen.
Werner B. wrote:
> Ich glaube eher dass da alte cygwin DLLs im Pfad liegen.
Ich bin von der Autorität, mit der Martin schreibt, deutlich
überzeugter als von deinem Glauben. ;-) Schließlich ist er der
Autor von WinARM.
Hi, I tried new WinAVR today under Win98SE and have the same problem. It's not due to cygwin dlls. I played a bit aroud and found that if I replase avr-gcc.exe by older version (I use 4.1.1 prerelease) the _spawnv message disappear but another problem rise: compiler will not find AVR header files. The problem is somewhere in cc1.exe older version worked OK. there was also some warning about zero EEPROM. Hm so I revert back my 4.1.1 prerelease and update only some parts (utils, avrdude, inlude and libs)
Martin Thomas wrote the detail of the reason above.
I have written an e-mail to Eric Weddington with my suggestion to fix this issue based on my "workaround" for the arm-elf-gcc in WinARM. He answered that he will try to incorporate the suggested fix in the avr-gcc of the next WinAVR-release. The new version should be available soon. Martin Thomas
Hallo
ich komm einfach nicht klar mit dem Problem:
> "make.exe" all
make.exe: *** No rule to make target `all'. Stop.
> Process Exit Code: 2
> Time Taken: 00:01
Hab zwar versucht mit der Lösung vom 6.1. :
jetzt habe ich im Notepad einen eigenen Befehl definiert:
make.exe all
mit meinem Pfad als Arbeitsverzeichnis und es geht.
Scheint also dass das eingebaute "make all" eine anderen makefile
nimmt??
klarzukommen, es funkt aber einfach nicht.
Kann mir jemand den Tipp geben, wie mann den Befehl make.exe all im
Notepad 2 unter TOOLS mit den Verzeichnissen (richtig) eingibt, damit
ich sichergehe, dass ich alles richtig gemacht habe.
Habe Notpad2 Version V2.0.6.1. ella unter XP.
Hallo zusammen Habe gestern auch WinAvr mit dem Programmer Notepad 2 installiert und das selbe Problem: > "make.exe" all rm -rf *.o *.elf *.hex *.map *.lst *.d process_begin: CreateProcess((null), rm -rf *.o *.elf *.hex *.map *.lst *.d, ...) failed. make (e=2): The system cannot find the file specified. make.exe: *** [clean] Error 2 > Process Exit Code: 2 > Time Taken: 00:00 Wäre super, falls hier jemand weiterhelfen könnte/würde. Vielen Dank Geri
Soweit ich das beurteilen kann, haben die beiden letzten Problemberichte
nichts mit dem _spawnv-Fehler des OP zu tun.
@ "Konny": Wenn in Programmer's Notepad bei Tools als Verzeichnis %d
angegeben ist, wird erst ins Verzeichnis gewechselt, in dem das grade
bearbeitete Dokument ("aktiver Editor-Tab") abgelegt ist. Könnte die
Ursache für das Problem sein. Bin grade nicht sicher, wie die Tools bei
WinAVR eingerichtet werden. Wenn es so ist wie bei meiner
WinARM-Konfiguration, reicht es das Makefile im Editor zu öffnen (oder
eine Datei die im selben Verzeichnis wie das Makefile abgelegt ist) und
dann "make all" aus dem Tools Menü aufzurufen. Habe meine
WinARM-Konfiguration mal angehängt (ich nutze diese für WinAVR und
WinARM). Einfach ins Verzeichnis .../pn/tools kopieren.
@ Gerhard Burger: Sind die Suchpfade richtig gesetzt? Es scheint, als
würde rm.exe nicht gefunden. Ist c:\WinAVR\utils\bin (zusätzlich zu
c:\WinAVR\bin) im Systemsuchpfad (PATH)? Das sollte das WinAVR
Installationsprogramm eigentlich in der Standardeinstellung so
einrichten. Im Zweifel deinstallieren und nochmal installieren mit
Standardeinstellungen ("add to path" o.ä eingeschaltet)
Martin Thomas
Hallo Martin Genau hier lag das Problem. Habe die beiden Pfade, welche du genannt hast, in der Systemsteuerung -> System -> Environment variables gesetzt und siehe da, es funktioniert. path: c:\program files\WinAVR\bin;c:\program files\WinAVR\utils\bin; Vielen Dank für die kompetente Unterstützung!! Geri
> avr-gcc: _spawnv: No such file or directory Dieser Fehler ist leider auch mit WinAVR 20070122 noch vorhanden. Testsystem ist Windows98SE. Hier die Debugausgabe des Compileversuchs (avr-gcc -v test.c -o test.elf): Using built-in specs. Target: avr Configured with: ../gcc-4.1.1/configure --prefix=/c/WinAVR --target=avr --enable-languages=c,c++ --with-dwarf2 --enable-win32-registry=WinAVR --disable-nls --disable-libssp --disable-fixincludes --disable-libada --with-gnu-ld --with-gnu-as --enable-doc Thread model: single gcc version 4.1.1 (WinAVR 20070122) d:/winavr/bin/../libexec/gcc/avr/4.1.1/cc1.exe -quiet -v -iprefix d:\winavr\bin\../lib/gcc/avr/4.1.1/ test.c -fno-delete-null-pointer-checks -quiet -dumpbase test.c -auxbase test -version -o f:\temp/ccn38cgb.s avr-gcc.exe: _spawnv: No such file or directory Im Anhang ist die Logausgabe von FILEMON (www.sysinternals.com). Im nächsten Posting ergänze ich das durch das Logfile der WINAVR-20060125 Version, die rennt unter Windows98SE problemlos.
Dieses Posting hat im Anhang das Logfile der WINAVR-20060125 Version, die rennt unter Windows98SE problemlos. Ein Wort in eigener Sache ;-) Wieso Windows98SE? Ein uraltes OS ohne Support... Das stimmt, jedoch habe ich Rechner im Einsatz, die vor paar Jahren gut waren. Ich bin der Meinung, dass die für meine paar µC-Projekte (Edit, Compile, Debug, Burn, Connect) noch dicke leistungsfähig genug sind. Leider sieht es die Softwareindustrie insbesondere M$ anders und das wird sicher wohlwollend von den Hardwareherstellern gesehen. Ich hoffe, dass die OpenSource-Gemeinde diesem Trend nicht unnötigerweise folgt. Wechsel zu Linux... Das wäre die Alternative. Leider bin ich WinAVR und AVRStudio verwöhnt und klammere mich noch an jeden Strohhalm.
ADD: Wenn ich auf irgendeine Art bei der Entwicklung eines Window98SE kompatiblen WinAVR helfen kann, tue ich das sehr gerne!
Eric fragen, ob er meinen Vorschlag mit der modifizierten pex-Datei übernommen hat. Wenn ja, dann muss man an anderer Stelle suchen. Wenn nein, MinGW/minsys installieren, gcc-quellcode (4.1.1) herunterladen, gcc-patchen für neue AVR (patches sollten im WinAVR-packet enthalten sein), pex-Datei patchen und das Ganze übersetzen, binutils und avr-libc kann man wahrscheinlich aus dem WinAVR-Packet übernehmen. Anleitungen zum Zusammenbau von (avr-)gcc unter MinGW finden sich. Unter Cygin kann man wahrscheinlich 1:1 die Anleitungen für Linux/BSD/"Unix" übernehmen. Damit ergeben sich zwar im Gegensatz zu MinGW Abhängigkeiten zu den cygwin-DLLs aber spart evtl. Zeit.
Es sieht so aus, als ob der pex-Patch nicht eingebaut ist. In den Patchfiles von WinAVR ist mit einer Textsuche "pex" nichts zu finden. Ich habe dann in dem WinARM von dir nachgesehen, ob ich den Patch finde. Meine Version (die Zwischenversion 20060531) hat keine Patchfiles dabei. Hast du den Patch auf deiner Seite in der offiziellen Version 20060606 drin, wenn ja muss ich mal updaten. MinGW ist bereits installiert, Cygwin auch. Vorm Übersetzen des GCC habe ich allerdings Respekt.
Einen GCC zu compilieren, ist nicht sehr schwer. Die nötigen Patches zusammenzukramen, könnte mehr Herausforderung sein, aber die hat ja wohl Eric schon irgendwo hingelegt, wenn ich dich recht verstehe. Allerdings solltest du dich wohl perspektivisch für deine Kiste(n) doch mal nach einem anderen Betriebssystem umgucken. Es wird immer mehr derartige Ecken und Kanten mit dem alten MS-DOS mit grafischem Betriebs- systemaufsatz geben, und nicht in jedem Falle wirst du sie durch selbst Compilieren beheben können. Der nächste dürfte in Form von AVR Studio selbst daher kommen (für dich ja der wesentliche Grund, kein unixoides System stattdessen zu benutzen). Die benutzen den XML-Parser von Microsoft, und Microsoft liefert für den auf den alten Systemen auch keine Bugfixes mehr. Ich habe auch noch einen Toshiba Libretto mit 32 MiB RAM, den ich für meine AVR-Arbeiten benutze. Aber mit FreeBSD und einem schlanken Windowmanager (statt irgendwelcher KDE- oder Gnome-Kolosse) lässt sich das Teil noch ganz passabel benutzen. In letzter Zeit hol' ich ihn aber doch immer seltener aus der Kiste. Man merkt ihm langsam an, dass ich ihn Ende 1999 bereits als abgelegtes Maschinchen gekauft habe, weil er einem Windows-Jünger eben damals bereits zu dünn geworden war...
Eine Anleitung zum Erstellen von AVR-GCC unter Windows gibts auch auf meiner Homepage: http://homepage.hispeed.ch/peterfleury/avrgcc_411_windows.html Es braucht kein Cygwin, lediglich MinGW. Mit Win98SE habe ich nie getestet, habe meinen alten PC längst verschrottet. Deshalb habe ich keinen pex-patch integriert. Aber es sollte nun nicht so schwierig sein, gemäss meiner Anleitung den pex-patch noch zusätzlich zu integrieren. Überhaupt kann ich es jedem empfehlen, sich mit dem selbst kompilieren von AVR-GCC zu beschäftigen. Es macht einfach Spass, immer eine aktuelle Version benutzen zu können. P.S. Meine Anleitung erzeugt noch 16-bit dwarf Debug Format für AVR Studio 4.12. Ich habe bis jetzt nicht untersucht, was man konfigurien oder patchen muss für 32-bit debug Format.
Danke für die Hinweise! Ich muss dann mal abwägen, was ich als nächstes mache. Moderneres Windows installieren, auf Linux umschwenken oder Toolchain selber bauen.
Kann gut verstehen, dass man noch Win9X-"Kisten" oder ein Multiboot-System am "leben" halten muss. Ich habe hier auch einige Software, die v.a. wegen Dongle-Schutz (bez. den Dongle-"Treibern") nicht mit WinNTff funktioniert. Für eine GNU(-cross)-Toolchain ist aber ein WinNT/2K/XP schon besser, kaum jemand testet noch mit Win9X. Ich nutze selbst (immer noch) einen recht betagten Rechner mit Win2k (PII-400 mit 3*128MB RAM) als Elektronik-Bastelrechner. Dieser ist ausreichend schnell zur Nutzung der GNU-Toolchains aus WinAVR und WinARM. Falls es also nicht grade ein PI-133-Rechner mit 64MB RAM ist, kann man mit einer W2K-Lizenz und evtl. etwas RAM (sollte bei e-bay billig zu haben sein) schon weiter kommen, ohne die gewohnten MS-Pfade zu verlassen. Ob sich das noch lohnt, muss man selbst entscheiden. Ich lege bisher bei WinARM keine Patch-Dateien bei. Ist für die nächste Version geplant, aber vielleicht dann auch nicht mehr notwendig. Wie auch immer: habe die bei WinARM genutzte pex-Datei Datei (ist nicht die aktuelle CVS/SVN-Version) und das Original aus dem gcc 4.1.1-Quellcode zum Vergleich hier abgelegt: http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/winarmtests/pex-win32_patch_gcc411.zip Die Code darin hat nichts mit dem Target zu tun, sondern nur mit dem Host (hier also Win32) ist also nicht ARM- oder AVR-spezifisch. Mit der modifizierten pex-win32, den Patch-Dateien für binutils/gcc aus WinAVR 1/07 und Peter Fleury's Anleitung sollte man weiterkommen. Martin Thomas
Danke Martin!
Ich habe gestern abend den 4. Weg eingeschlagen: Nachforschen, woher die
Probleme wirklich kommen. Das wird noch einige Zeit in Anspruch nehmen
und der Ausgang ist noch offen...
Im Moment sieht es nach einer Inkompatibilität bei der _spawnv-Funktion
in den Laufzeitbibliotheken msvcrt.dll von Windows98SE
("Produktionssystem", Version 6) und von XP ("Testsystem", Version 7)
aus.
_spawnv() bereitet letztlich den Kommandozeilenstring für
CreateProcess() vor. Möglicherweise helfen die Untersuchungen deshalb
auch bei dem Vista-Problem mit CreateProcess() (msvcrt.dll Version 8?).
Ich beobachte, dass selbst bei einem einfachen Compilerlauf die an cc1
übergebene Argumentliste signifikant länger ist als unter dem älteren
WinAVR und dass unter Windows98SE die Argumentliste in der
commandline-Version abgeschnitten ist. Der XP-Versuch steht noch aus.
Wer/Was für das Abschneiden verantwortlich ist, weiss ich noch nicht.
Kandidaten dafür sind _spawnv(), CreateProcess() oder Hilfsfunktionen in
GCC (pex-win32.c). Alle drei Punkte werde ich abklopfen...
Zu den Hilfsfunktionen: Vor dem _spawnv() werden die Argumente für die
Toolchain durch fix_argv() in pex-win32.c manipuliert. Dadurch sollen
bestimmte M$ Unzulänglichkeiten bei der Umwandlung der Argumentliste
char *argv[] nach char *commandline behoben werden.
_spawnv() wird mit der gefixten Argumentliste aufgerufen und meldet sich
mit dem bekannten Fehler zurück. cc1 wird dabei noch nicht gestartet,
d.h. innerhalb _spawnv() wird bereits ein Fehler erkannt und nicht erst
im aufgerufenen Child-Programm. Ob _spawnv() in dem Moment schon an
CreateProcess() übergeben hat, muss ich noch prüfen.
Es bleibt spannend ;-)
Wenn man es pragmatisch betrachtet, würden 2 Bytes über das Schicksal von AVR-GCC 4.1.1 unter Windows98SE entscheiden. 2 Bytes, weil ich das Problem noch nicht auf Sourcecodeebene eingrenzen konnte und daher einen Binärpatch als Workaround verwende. Denn die beiden pex-win32.c Versionen in obigem Archiv passen noch nicht zu dem, was ich mit dem Disassembler/Debugger innerhalb von avr-gcc.exe sehe. Ich brauche wahrscheinlich das Wochenende, um auf Sourcecodeebene weiterzukommen. Der Programmablauf innerhalb des unbekannten pex-win32.c müsste so aussehen: pex... bekommt im wesentlichen Namen inkl. Pfad des aufzurufenden Childprogrammes (executable) sowie eine Liste mit Argumenten (argv[]). Die GCC interne Repräsentation des Programmnamens inkl. Pfad hat komplett Slashes als Verzeichnistrennzeichen. Das ist unabhängig davon, ob die Environmentvariable PATH Slashes oder Backslashes benutzt. Hilfsfunktionen für die Windows-Portierung kopieren Duplizieren die Strings aus argv und legen eine neue Argumentliste an (newargv). Dabei werden bei newargv[0] Slashes nach Backslashes konvertiert (backslashify()). Je nach pex-win32.c Version werden noch weitere Konvertierungen mit den anderen Argumenten gemacht. _spawnv() wird aufgerufen. ABER es wird als Programmname der unkonvertierte GCC-interne Programmname verwendet (z.B. _spawnv(mode, executable, newargv)). In CreateProcess() scheitert dieser Aufruf unter Windows98SE, wegen den Slashes. Die bekannte Fehlerbehandlung setzt ein. Mein Binärpatch verändert die Argumente von _spawnv(), so dass der Aufruf jetzt lautet _spawnv(mode, newargv[0], newargv). Mit dem Binärpatch kann avr-gcc.exe beim Aufruf per Kommandozeile kompilieren und beim Aufruf aus AVR Studio (Betaversion) auch. Ungetestet ist ein Aufruf per make. Ich befürchte, dass make.exe ein weiterer Kandidat für das gleiche Problem ist, weil es ebenfalls Childprogramme startet. Mal sehen. Die abgeschnittene Kommandozeile habe ich nicht mehr beobachten können. Es kann sein, dass das mit den vorhergehenden Tests zusammenhing. Diese hatte ich per Batchfiles mit der -### Ausgabe von avr-gcc.exe durchgeführt. Es kann sein, dass mit da die Shell einen Streich gespielt hat.
Was denn, in Win98/SE haben sie der Erkennung von Vorwätsstrichen als Pfadnamentrenner kaputt bekommen? Mannomann, das hat zurück bis mindestens MS-DOS 3.30 funktioniert...
Ein ganz seltsames Bild bei Windows98SE Die Windows-Funktion GetFileAttributes() verkraftet problemlos / im Pfad. Diese Funktion wird von _spawnv vor CreateProcess() aufgerufen, um festzustellen ob Child überhaupt existiert. CreateProcess() verkraftet auch / im Pfad, WENN gleichzeitig noch \ vorhanden sind. Nicht aber wenn NUR / vorhanden sind. Ich denke das ist der auslösende Bug bzw. die Inkompatibilität.
Die Befürchtungen zu 'make.exe' waren unbegründet. Make funktioniert von PN2 aus wie gewohnt. Nicht erfolgreich bin ich mit der simulavr/insight-Combo (buffer overflow in simulavrs gdbserver.c). Aber ich denke, das ist ein Problem der beiden untereinander und nichts Windows 98SE spezifisches. Im Moment sammele ich die Sourcen ein. Zum Reinkucken ;-)
There is an error with WinAVR-20070122 when running under Windows98SE: avr-gcc: _spawnv: No such file or directory The reason for the error is an ill-formatted pathname for the executable which is started by _spawnv. _spawnv is a function in MSVCRTL.DLL (Visual C++ Runtime Library). _spawnv is caller of CreateProcess of the Windows API. CreateProcess has some difficulties with pathnames with slashes on Windows 98SE and throws the error above. I tried to fix this error in order to run the toolchain under Windows98SE and i think this was successful. BUT i could get AVR-GCC.EXE working on my machines (Windows 98SE and Windows XP SP2; both with Programmers Notepad 2 and AVRStudio 4.13 Beta) with a binary patch of AVR-GCC.EXE. The binary patched AVR-GCC.EXE is included in the attached achive. IMPORTANT: I didn't compile an AVR-GCC.EXE from the pachted source code!!! Use AVR-GCC.EXE on your own risk or stay away from it. BUT I could not find the C source code file which was used when WinAVR-20070122 (GCC 4.1.1) was compiled. Even when i tried to get the source code from http://gcc.gnu.org/viewcvs/trunk/libiberty/pex-win32.c?view=log I compared revision 118595 down to revision 97125 of pex-win32.c with the ix86 disassembly of AVR-GCC.EXE. The disassembly of the function pex_win32_exec_child() is in the attached archive. You see the binary patch in lines 151-152. And you see some code labeled UNKNOWN_PART in lines 125-138. I couldn't be find the unknow part in the revisions above. I want to give you a clue how the patch might look in C source code. Therefore i patched the newest source code (revision 118595). What is done by the binary patch is now in this C source too. Now with the patch _spawnv gets a backslashified pathname (newargv[0] instead of executable). I really hope someone with more understanding of GCC compilation and insight in the source code tree can do something with this information. AGAIN: I didn't compile an AVR-GCC.EXE from the patched source code!!! Use AVR-GCC.EXE on your own risk or stay away from it. Stefan Brueck 02/02/2007
I swapped the original AVR-GCC.exe with Stefans patced version and after a reboot it worked, but haven't tested it yet much
I tried again the combination WinAVR-20070122 with AVRStudio 4.13. When i do New Project, everything is fine. But when i do Open Project or Recent Project, then sometimes i get an exception in OLEAUT32.DLL. A stack trace shows that the exception comes from Configuration::<something> in AVRGCCPlugin. A pointer is invalid for two subsequent calls. I went back to AVRStudio 4.12 SP4. And in order to work with 32-bit elf/dwarf-2 i substituted the folder Parsers in 4.12 with the same folder from 4.13.
I also tried Stefan's patch (binary) and it seems to work under win98. I recompiled all my projects sucessfully. THX.
> I tried again the combination WinAVR-20070122 with AVRStudio 4.13.
With a super ultra clean deinstallation of all Atmel Tools before.
And... it (4.13) is working like a charm now ;-)
I had the same problem but under Windows XP SP2 !!! It works fine with patch for win98 uploaded from this site.
Für WinAVR 20070525 gibt es den Win98SE-Patch hier: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=325572#325572 (50.54 KB)
Ich finde da nichts ? Da wird was von Anhang gesabbelt, aber den gibt es nicht.
Danke, dass du meine Nachricht dort als Gesabbel abtust. Hast du schon mal überlegt bzw. nachgelesen, ob sich dort nur registrierte User Anhänge runterholen können?
@ Stefan Entschuldige bitte meine Wortwahl. Ich dachte mir SCHON so etwas in der Art. Finde es aber nicht besonders schön das man erst mal wieder einem Club beitreten muss um neuere WINAVR Versionen benutzen zu können. Nichts für ungut und danke für den Patch !
@Stefan B. Danke, Danke, Danke!! Ich schiebe jetzt vielleicht den Beitrag unnötig nach oben, aber dass ist es mir Wert. Hab mich Gestern (XP Rechner SP2 alle aktuellen patches) min. 6h gespielt und habs nicht verstanden warum ich diesen Fehler bekomme. Heute in der Fa. , mit gleichem OS und selben Projekt, probiert und es funktionierte einwandfrei. Jetzt, zufällig diesen Beitrag entdeckt und den Patch "installiert", und es geht. Wie gibt es dass, auf einem Rechner gehts am andern nicht?? Warum wird diese Änderung am Source nicht gleich in das offizielle Release integriert da es sich offensichtlich (zumindest bei mir) nicht nur auf Win98SE beschränkt? Würde zumindest damit ein paar verzweifelte Menschen weniger geben ;-) lg und noch mal Thx Rudi
>Warum wird diese Änderung am Source nicht gleich in das offizielle Release >integriert da es sich offensichtlich (zumindest bei mir) nicht nur auf >Win98SE beschränkt? Würde zumindest damit ein paar verzweifelte Menschen >weniger geben ;-) Nicht nur ein paar verzweifelte Menschen :( Du bist nicht allein ! W98SE geht bei mir nicht, WXP geht bei mir nicht. Nur mit Patch. Mit welchem Windows funktioniert der neue WINAVR eigentlich ohne Patch ? Das Problem ist schon seit Anfang 2007 bekannt. Die Lösung auch. Gibt es wirklich niemanden der den Patch von Stefan in den offiziellen WINAVR reinprügelt ?
Es hängt - bei meinem Windows98SE - eigentlich an einer Hilfsbibliothek (DLL) von Windows und zwar ist es die Microsoft C Runtime Library in einer verflixten Version. Leider ist es bei Windows so, dass manche Anwendungen das System kontaminieren können, in dem sie diese Microsoft C Runtime Library (oder andere) - vom Programmierer vielleicht gut gemeint - beim Installieren der Anwendung "auf den neusten Stand" bringen. Und je nach Alter der Anwendung ist das vielleicht nicht die fehlerärmste Version einer Library... Nicht umsonst gibt es den Begriff DLL Hell (http://de.wikipedia.org/wiki/DLL_Hell) Bei den AVRFreaks hatte ich dazu mal geschrieben: Maybe this is fixed in later MSVCRT.DLLs on other Windows systems. I have MSVCRT.DLL version 6.10.9844.0 from Visual C++ 6. More investigations would require debugging different MSVCRT.DLL versions on different Windows systems. http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=325572#325572 Der Patch ist dort auch für WinAVR 20070525 hinterlegt. Da der Download dort nur nach Registrierung möglich ist, hänge ich die Datei auch hier an. Ich bin nicht glücklich mit den Binärpatches. Ich sähe es lieber, wenn die Änderung in die GCC Sourcen einfliessen würde und ab dem nächsten Mal kein Patch mehr notwendig ist. Aber ich war wohl nicht geschickt genug, diesen Wunsch entsprechend gut zu verkaufen. Ein Fünkchen Hoffnung habe ich noch für die nächste WinAVR Version. Vielleicht klappt es dann. Hinzukommt, dass es unter meinem Windows 98SE zu sporadischen Problemen mit dem (für GCC in AVR Studio erforderlichen) neuen AVR Studio kommen kann. Plötzlich lassen sich Projekte nicht mehr öffnen und AVR Studio schmiert ab. Ich hoffe, dass der aktuelle Servicepack vom AVR Studio das behebt, zumindest habe ich Diskussionsbeiträge in dieser Richtung gelesen. Aber das muss ich selbst auch noch in Ruhe ausprobieren.
Mir ist das mit dem Fehler unter Schweissausbruch auch aufgefallen. Ich das unter Programmers Note-Pad am laufen. Ich habe bemekt das ich diesen Fehler umgehen kann, indem ich das Fenster indem der Make-File sichtbar ist, als erstes offen im Editor sichtbar habe. Die anderen Editor-Fenster mit dem z.B C-Quell-Code sind alle vorsichtshalber geschlossen zu halten. Dan erst wird der Make-Button im Menu geklickt, und somit startet die Compile-Aktion mit dem Make-File ohne Fehler. Könnt das der Grund sein, weil nur wenn das "Make-File" im Editor sichtbar ist ( also nur dieses Makefile on Top liegt ), der Argv[] für das Compile-Prog erst damit in dieser speziellen Konstelation Fehlerfrei übergeben werden kann ????. Der Compiler kann ja auch in der Dos-Box über Dos-Kommando make makefile ausgeführt werden..... Und das Output-Fenster für die Compile errors ist wie ich vermute auch so ein umgeleiteter Consolen-Print, wen das unter Window-System im Window läuft. Ich habe das auch so bei WIN-Vista ausprobiert u. so gemacht. Mit diesem mystischen Kniff hoffe ich für die Zukunft klarzukommen. Gruss Holger.Harten
Meine Hoffnung hat sich leider nicht bestätigt. Sowohl AVR STudio SP1 Build 555 als auch AVR Studio SP1 Build 557 haben weiterhin sporadische Probleme. Auf meiner Maschine hängt es irgendwo bei der Initialisierung des GCC Plugins aus AVR Studio heraus. Das ist aber eine ganz andere Ecke als die WinAVR-Problematik. Ich vermute vom Debugger-Bild her (Absturz tief in den OLE-Routinen von Windows), dass die (zugekaufte) GUI-Oberfläche/Library des AVR Studios der Auslöser ist. Deinen Tipp, Holger, werde ich mal noch ausprobieren. Ich kann mir gut vorstellen, dass es einen Einfluss hat, welche Fenster offen sind und welche nicht. Auf Dauer werde ich wohl eine Linux-ähnliche Arbeitsumgebung mit einer IDE meines Vertrauens ;-) einrichten und nur WinAVR nutzen und auf AVR Studio verzichten.
Hi It can help somebody so I decided to write how I resolved the problem: avr-gcc: _spawnv: No such file or directory (I don't speak german but I understood the topic ;-) I have Win XP. And I found out that my firewall had blocked the avr-gcc.exe So I added it to friendly applications. That's all :-)
I'd like to thank Stefan Brueck very much for the patch. avr-gcc in my Ubuntu Feisty has a problem with the at90usb1287 chip and my Win98 has that problem with with avr-gcc so I was stuck. The patch is working very nicely. It's very cool how he did it too.
WinAVR-20071221 funktioniert bei mir unter Windows98SE direkt nach der normalen Installation. Es ist kein Binärpatch mehr notwendig.
@jas TNX A LOT!! THATS IT!! The hours of frustration has an end XD. I'm using xp-sp3 with an "Arduino Diecimila" board and I don't know how, but the firewall (Agnitum Outpost v4.x) causes the problem. I deactivate it, and it works fine..
after a few years spended with @megas with different compillers, also 3 years with winavr third robot second big msc job and in so important moment.. in a few weeks before its(above) end.. _spawvn strikes aaaghhrrr thanks, ppl (sorry, aber my deutsch schlieft jetzt)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.