Forum: Compiler & IDEs avr-gcc: _spawnv: No such file or directory


von Dieter (Gast)


Lesenswert?

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?

von Dieter (Gast)


Lesenswert?

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!

von Werner A. (homebrew)


Lesenswert?

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

von Dieter (Gast)


Lesenswert?

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?

von Dieter (Gast)


Lesenswert?

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.

von Martin Thomas (Gast)


Lesenswert?

"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

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


Lesenswert?

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.

von Werner B. (Gast)


Lesenswert?

Ich glaube eher dass da alte cygwin DLLs im Pfad liegen.

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


Lesenswert?

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.

von RayeR (Gast)


Lesenswert?

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)

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


Lesenswert?

Martin Thomas wrote the detail of the reason above.

von Martin Thomas (Gast)


Lesenswert?

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

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


Lesenswert?

Danke, Martin!

von RayeR (Gast)


Lesenswert?

OK, I'll forward on next release

von Stefan (Gast)


Lesenswert?

Great news! Thanx.

von Dieter (Gast)


Lesenswert?

Thanx

von Konny (Gast)


Lesenswert?

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.

von G. B. (geri)


Lesenswert?

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

von Martin Thomas (Gast)


Angehängte Dateien:

Lesenswert?

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

von G. B. (geri)


Lesenswert?

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

von Stefan (Gast)


Angehängte Dateien:

Lesenswert?

> 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.

von Stefan (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Stefan (Gast)


Lesenswert?

ADD: Wenn ich auf irgendeine Art bei der Entwicklung eines Window98SE 
kompatiblen WinAVR helfen kann, tue ich das sehr gerne!

von Martin Thomas (Gast)


Lesenswert?

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.

von Stefan (Gast)


Lesenswert?

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.

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


Lesenswert?

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...

von Peter Fleury (Gast)


Lesenswert?

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.

von Stefan (Gast)


Lesenswert?

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.

von Martin Thomas (Gast)


Lesenswert?

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

von Stefan (Gast)


Lesenswert?

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 ;-)

von Stefan (Gast)


Lesenswert?

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.

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


Lesenswert?

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...

von Stefan (Gast)


Lesenswert?

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.

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


Lesenswert?

Schräg...

von Stefan (Gast)


Lesenswert?

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 ;-)

von Stefan (Gast)


Angehängte Dateien:

Lesenswert?

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

von Manfred (Gast)


Lesenswert?

I swapped the original AVR-GCC.exe with Stefans patced version and after 
a reboot it worked, but haven't tested it yet much

von Stefan (Gast)


Lesenswert?

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.

von RayeR (Gast)


Lesenswert?

I also tried Stefan's patch (binary) and it seems to work under win98. I 
recompiled all my projects sucessfully. THX.

von Stefan (Gast)


Lesenswert?

> 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 ;-)

von Fester (Gast)


Lesenswert?

I had the same problem but under Windows XP SP2 !!!
It works fine with patch for win98 uploaded from this site.

von Stefan B. (stefan) Benutzerseite


Lesenswert?

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)

von Blinder (Gast)


Lesenswert?

Ich finde da nichts ? Da wird was von Anhang gesabbelt,
aber den gibt es nicht.

von Stefan B. (stefan) Benutzerseite


Angehängte Dateien:

Lesenswert?

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?

von Blinder (Gast)


Lesenswert?

@ 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 !

von Rudi (Gast)


Lesenswert?

@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

von holger (Gast)


Lesenswert?

>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 ?

von Stefan B. (stefan) Benutzerseite


Angehängte Dateien:

Lesenswert?

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.

von Holger Harten (Gast)


Lesenswert?

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

von Stefan B. (stefan) Benutzerseite


Lesenswert?

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.

von jas (Gast)


Lesenswert?

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 :-)

von John McKown (Gast)


Lesenswert?

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.

von Stefan B. (stefan) Benutzerseite


Lesenswert?

WinAVR-20071221 funktioniert bei mir unter Windows98SE direkt nach der 
normalen Installation. Es ist kein Binärpatch mehr notwendig.

von lorian (Gast)


Lesenswert?

@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..

von ts/air/put/pn/pl (Gast)


Lesenswert?

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)

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.