Wollte nur mal auf die offizielle Ankündigung verweisen: http://sourceforge.net/forum/forum.php?forum_id=446217 Sorry, richtigen Nerv für eine Übersetzung habe ich gerade nicht. Wer die Version gestern schon mal geholt hat, sollte nochmal updaten, es haben sich paar Kleinigkeiten geändert (irgendein PN2-Problem wurde repariert, avr-libc ist als 1.2.3 dabei [ein Bugfix mehr, daher die neue Version], SRecord war wohl gestern auch nicht dabei).
Hallo Jörg, sehr schön und gleich probiert: Manche Projekte laufen ohne Änderung durch (gleiche Text.Segment Grösse) andere fallen mit der std. make Fehlermeldung "*** No rule to make target....". Das unabhängig vom Pfad der Quellen oder des CPU Typs. Kopiere ich ein funktionierendes makefile in ein Projekt mit nicht funktionierendem Makefile und ändere die Filenamen -> Fehler bleibt! Also, 3.4.3 bringt's wohl noch nicht so..., weiter warten.... 73, Andreas
Huh, was haben deine Makefile-Probleme mit der Compilerversion zu tun? Ungefähr genauso viel wie mit der aktuellen Mondphase, nur dass ich diese zumindest genau bestimmen kann: % pom The Moon is Waxing Gibbous (56% of Full) :-) Also: wenn du Hilfe zu deinen Makefiles brauchst, dann poste konkret. Ansonsten wäre Mfile noch anzuraten (bisschen Eigenwerbung, aber ich habe fast nur positive Rückmeldungen von denjenigen, denen ich bislang dazu geraten habe).
Hallo Jörg, habe bisher auch immer gedacht Makefiles wären Compiler/Projekt unabhängig. Sind übrigens nicht MEINE makefiles, habe da nur wenige Source-File-Namen eingetragen/ausgetauscht, sonst so belassen! Ging bisher immer einwandfrei. Habe zum Test ein makefile mit MFILE generiert, dann Dateinamen eingesetzt -> gleiche Fehlermeldung! Werde weiterforschen. System: W2K alle S-Packs. Gruß Andreas
Dann musst du schon konkret werden. Am besten Makefile posten mitsamt der exakten Fehlermeldung. Wie gesagt, mit'm Compiler hat das alles nix zu tun. Achso, die übliche Kapserfalle: stelle sicher, dass das richtige make genommen wird. Nicht dass du ein Borland make oder sowas zuerst im PATH hast...
Auch kein Problem.... Wenn ich make mit einem einzelnen Namen aufrufe, also z.B. "make ds2.c", dann meint make es gäbe nix zu tun..., obwohl das 'ds2.o' file noch gar nicht existiert! Dos-Box Ausgabe: -------- begin -------- avr-gcc (GCC) 3.4.3 Copyright (C) 2004 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. make: *** No rule to make target `ds2.o', needed by `ds2.elf'. Stop. Andreas
Du musst ja auch »make ds2.o« sagen, schließlich ist es doch die .o-Datei, der er machen soll -- die .c-Datei ist ja da, die muss er nicht mehr machen (daher sagt er auch, dass er für die nichts mehr zu tun hat). Habe dein Makefile hier in ein Verzeichnis kopiert, eine ds2.c mit einem leeren main() erzeugt sowie zwei leere Dateien pindrv.c und debug.c => funktioniert tadellos. Ich habe den Verdacht, dass du gar kein ds2.c im entsprechenden Verzeichnis hast...
Ich glaube das führt hier zu nix. Wenn Du anzweifelst, dass ich keine C Projekte bauen kann, macht weiterdiskutieren keinen Sinn! Ich hatte wohl schon erwähnt, dass das Projekt mit GCC 3.4.1 einwandfrei lief, oder? Ich hatte, glaube ich, auch erwähnt, das es Projekte gibt, die WEITERHIN einwandfrei laufen (sich compilieren lassen) und andere bocken halt. Egal, da kein Text.Size Gewinn -> back to 3.4.1 ! By the way: beim ARM hat GCC 3.4.3 gegen 3.4.1 ziemlich viel Text.Size Gewinn gebracht. Meist durch intensives Inlining wodurch besser optimiert werden kann. 73, Andreas
Ja, ich zweifle an, dass Makefile-Probleme etwas mit der Compilerversion zu tun haben. Der Compiler wird nämlich gar nicht aufgerufen (zumindest in einem der Fälle). Kann ja sein, dass es eine Abhängigkeit von der make-Version gibt und du durch das neue WinAVR auch eine andere davon hast, aber mit dem Compiler hat das wirklich nichts zu tun. Im Zweifelsfalle solltest du den Compiler auch einfach mit der Hand (oder mit einem Batchfile) aufrufen können, wenn du mir das nicht glaubst. make ist ja keine Pflicht, sondern nur ein (normalerweise) bequemes Tool. Du kannst mir gern die Ausgabe von make -d senden, für alle Fälle noch ein Listing des Verzeichnisses dazu. Bitte aber als Mail (sorry für das ASK, aber ich bekomme auf dieser Mailadresse unheimlich viel Müll angeliefert), das ist ziemlich groß für hier. Oder auch gleich den Inhalt des Verzeichnisses als ZIP oder .tar.gz mit mailen, wenn das kein Problem für dich ist.
Jörg, hat sich alles erledigt. Ich habe das neu MAKE.EXE (C:\winavr\utils\bin\make.exe) durch das ALTE von 3.4.1 kommende make.exe ersetzt, und voila .... alles geht wieder! Das aktuelle make.exe scheint da noch nicht ganz ausgereift zu sein. Danke trotzdem für Deine Bemühungen, will die hier nicht niedermachen! Erstmal zufrieden, Andreas
Nein, nein, das kann nicht der Weg sein. Kopf in den Sand und alte Versionen nehmen... Versteh' doch mal, bei Dir tritt der Bug auf, bei sonst keinem (so'nen Bericht habe ich jedenfalls bislang noch nicht gelesen). Wenn du daher willst, dass der Bug auch mal beseitigt werden kann und nicht in der nächsten und übernächsten Version auch noch drin ist, dann musst du da schon ein Stück mithelfen. Wie geschrieben, die Ausgabe von make -d wäre schon recht hilfreich. Wenn man damit einen einfachen Testfall zimmern kann, bei dem das passiert, kann man bei GNU Make einen Bugreport aufmachen. Ich habe übrigens hier auf meinem FreeBSD dieselbe Version von GNU make (3.80) wie du auch, da tritt der Bug nicht auf, mit deinem Makefile hat hier alles geklappt. Irgendwo muss es also an deiner Umgebung liegen.
OK, einfach die alte MAKE.EXE zu nehmen ist reiner Pragmatismus. Habe den ganzen WINAVR Kram nochmal spasseshalber auf ein W98SE System gepackt und -> gleiches Verhalten: neues Make.exe geht nicht, altes make.exe geht. Das mag alles irgendwie mit meinem/unserem Systemaufbau zu tun haben, das kann schon sein, ist mir aber erstmal egal. Habe alle bestehenden Projekte kurz durchkompiliert (ohne Size Gewinn, schade) und damit ist gut. Habe Dir noch den Ausdruck von "make -d all" beigelegt. Die Fehlermeldung kommt dann aber direkt in der DOS-BOX und ist somit nicht im beiliegendem File. 73, Andreas
Jörg, falls Du das MAKEFILE noch beschauen willst.... Bitte schön 73, Andreas
Irgendwie findet das make deine C-Dateien allesamt nicht. Zum Vergleich, dein Logfile: Updating makefiles.... Considering target file `debug.d'. File `debug.d' does not exist. Looking for an implicit rule for `debug.d'. Trying pattern rule with stem `debug'. Trying implicit prerequisite `debug.c'. Trying pattern rule with stem `debug.d'. ... und weiter sucht er. Hier dasselbe, wenn ich das versuche: Updating makefiles.... Considering target file `debug.d'. File `debug.d' does not exist. Looking for an implicit rule for `debug.d'. Trying pattern rule with stem `debug'. Trying implicit prerequisite `debug.c'. Found an implicit rule for `debug.d'. Considering target file `debug.c'. Er hat ein debug.c gefunden und nimmt es. Ich weiß nicht, welche Art syscall-tracer oder sowas es bei Windows gibt, aber dort würde ich weitermachen mit der Suche. Ist das auch auf einem MS-DOS-Derivat passiert (Win95/98/ME)? Kannst du es mal auf einem WinNT-Derivat (NT4, Win2K, WinXP) probieren? Vielleicht findet dieses make-Compilat ja irgendwie wirklich keine Dateien. Ich bin mir nicht ganz sicher, aber wenn ich den syscall-Tracer hier auf FreeBSD an dieser Stelle richtig lese, dann versucht er nicht jedesmal einzeln, die entsprechenden Dateien zu öffnen, sondern liest das jeweilige Verzeichnis durch. Falls nun die beim Bau benutzten Bibliotheken mit dem Lesen von Verzeichnissen ein Problem haben, funktioniert zwar der Compiler (der öffnet eine Datei und benutzt sie), nicht aber eben das make. In jedem Falle würde ich dich bitten, bei WinAVR (sourceforge.net) mal einen Bugreport dafür aufzumachen.
Noch 'ne Frage, die Colin O'Flynn mir rübergebracht hat (der zweite Autor von WinAVR): tritt das Problem auch auf, wenn du das demo.c der avr-libc selbst compilieren willst? Er hat zumindest auf einem Win98 mit frisch installiertem WinAVR kein Problem, demo.c mit dem dort liegenden Makefile zu compilieren. Aber wie gesagt, vergiss nicht, einen Bugreport dafür aufzumachen. Bislang bist du wirklich der Einzige, der solche Probleme vermeldet.
Hallo Jörg, der MAKE.ERR Printout von gestern war von einer W98SE Maschinen, der hier angehängte stammt von einer W2K Maschine. Aus einer CMD-BOX gestartet: "make clean" dann "make -d all >>make.err" Alle Datein auf lokalem Datenträger C: Gleiches Fehlerbild, altes MAKE.EXE funktioniert, neues NICHT ! Kann damit aber erstmal leben. 73, Andreas
Und dazu noch das MAKEFILE, Warum kann man eigentlich nicht mehrere File uploaden ?!
Irgendwie ist das schon seltsam, kein Mensch kann dasselbe Problem irgendwie nachvollziehen, bei dir taucht es immer auf. (Und auf Win2K oder neuer haben es schon viele Leute in Benutzung.) Übrigens, auf WinNT+ geht auch make 2>&1 > make.log Damit hast du sowohl stdout als auch stderr im Log. cmd.exe ist halt doch ein bissel besser als das alte command.com. ;-)
"doch ein bissel besser als das alte command.com. ;-)" daran könnts vielleicht liegen. Wenn man im DOS-Fenster einen alten NC öffnet, dann führt der nur die command.com aus und die kennt keine langen Dateinamen. Z.B.: avr-objdump.exe -t -h -S %main%.out >%main%.lst wird dann nicht gefunden. Aber so gehts: cmd.exe /c avr-objdump.exe -t -h -S %main%.out >%main%.lst Peter
Da er ja erstens die Probleme konsistent zwischen cmd.exe und command.com hat und zweitens wirklich mit 8+3 auskommt, sollte es daran nicht liegen. Andreas, ich möchte Eric Weddington mal ein wenig unterstützen und habe dir unter http://uriah.heep.sax.de/outgoing/make-3.80.zip eine Version von GNU make 3.80 hingelegt, die etwas mehr Debugging aktiviert hat. Bitte starte die mal mit make -d > log 2> log und maile mir die Ausgabe. (Musst das nicht hier alles in Forum hängen, das interessiert sonst sicher niemanden.) Ich habe die Vergleichslogs von FreeBSD und Win2K dann hier (ja, dein Makefile geht bei mir anstandslos auf einer Win2K-Maschine, auch mit dem originalen GNU make 3.80, so wie WinAVR es installiert).
Hi Leute, da habe ich mir das heute morgen nur Interesse halber durchgelesen und schon passiert es :-) Genau das gleiche, einige Projekte laufen bei anderen kommt auch "No rule to make target `all" WinXP alle SP
NTFS Ich habe hier noch einiges merkwürdiges in diesem Zusammenhang bemerkt (Einfach so niedergeschrieben, bin nicht so gewandt im Programmieren): Benutze ich das neue makefile kommt: "No rule to make target all" bei alten kommt: "make.exe: No rule to make target main.o..." Eben konnte ich das Projekt compilieren, nachdem ich (meine) nichts weiter gemacht habe, als das MAKEFILE in makefile zu ändern. Da ich dann die neuere LCD Lib von Fleury einbinden musste habe ich make clean gemacht und wollte dann make all machen und nicht ging mehr. Ich werde mir das noch einmal in Ruhe anschauen und mich die Tage wieder äussern...
Ok, ich habe den Fehler bei mir (zum Teil) gefunden: Die Groß- und Kleinschreibung von makefile, lcd.h und so weiter. Was ich überhaupt nicht verstehe ist warum diese Dateien bei mir plötzlich GROß geschrieben sind. Ich habe das nicht geändert, das muss mit mfile und/oder PN zusammen hängen. Jedenfalls kann ich wieder lustig rumcompilieren, unabhängig vom makefile, sobald ich die Schreibweise geändert habe!?!? Hoffe etwas geholfen zu haben...
öffne mal DOS Box und gebe DIR ein. Vielleicht ist der Pfad zum Arbeitsverzeichnis verstellt. Man sollte ja meinen das heutige Programme unabhängig vom eingestellten Arbeitspfad funktionieren, aber selbst bei windowsbasierten Delphi 7 Kommandozeilentools muß der Arbeitspfad korrekt stehen, ansonsten findet er die Files nicht korrekt. Ich meine mal nur so als Idee. Gruß Hagen
Habe das Makefile aus dem Anhang zum Beitrag "16.02.2005 17:50" hier testweise in ein Projekt eingebunden. Lediglich die Namen der Quellcodedateien angepasst an hier vorhandenen Code fuer Mega8: ... MCU = atmega8 ... TARGET = matrix ... SRC = $(TARGET).c \ delay.c aktuelles WinAVR (14Feb), WinXP SP2, sowohl FAT32 und NTFS, "cmd.exe" als Start-"Shell" (die von make selbt genutze shell ist ein zsh-Win32-port) -> keine Probleme. Vielleicht wirklich "nur" Gross/Kleinschreibungsproblem wie von Dirk beschrieben. Martin
Das mit der Groß- und Kleinschreibung darf auf einem Windows-System aber eigentlich nicht zu solchen Fehlern führen - außerhalb der Posix-Emulationsumgebung (die, wie wir seit einer kürzlich geführten Diskussion wissen, eh' nicht mehr bei XP dabei ist) werden Groß- und Kleinschreibung von Dateinamen nicht unterschieden. Wenn gnu-make das anders handhaben sollte, würde ich das für einen Fehler in der Portierung des gnu-make halten.
Ja, genau das scheint's zu sein, soweit war ich mit dem Debuggen mit Andreas auch gekommen. Mfile ändert übrigens nichts an den Dateien (außer am generierten Makefile). Wie PN2 die Dateinamen anlegt, weiß ich nicht. Seltsamerweise hätte das früher eher auftreten sollen als jetzt, da früher das GNU make in WinAVR eine Cygwin- (also praktisch: Posix)- Applikation war, während es jetzt eine MinGW-(native Win32)- Applikation ist. Andererseits war das Verhalten bei Andreas unabhängig von MinGW32 oder Cygwin. Was für eine GNU-make-Version war eigentlich früher bei WinAVR dabei, kann das noch jemand sagen? Ich habe mir mal den Sourcecode der 3.78 zum Vergleich angesehen, alles Interessante sieht dort schon genau so ist.
Ein Vorteil ist natürlich, dass das Ganze auch Windowsnutzer nun dazu erziehen kann, in der Groß-/Kleinschreibung konsistent zu werden. Damit sind die Projekte dann wenigstens 1:1 auf Unix portabel. :-)
Naja, eher 1:0 portabel. Unter Windows ist halt datei.txt und DATEI.TXT (und alle Permutationen davon) dasselbe, während das unter Unix halt nicht der Fall ist. Somit kann ein Projekt, das Dateien enthält, deren Dateinamen sich nur in Groß- und Kleinschreibung unterscheiden, nicht ohne größeren Aufwand auf Windows portiert werden. Davon abgesehen hast Du natürlich recht - wenn ich im Makefile meine Dateinamen auf eine bestimmte Art und Weise schreibe, dann sollten die Dateien auch wirklich so und nicht anders heißen.
Klar, dafür habe ich noch keinen gesehen, der unter Unix vorsätzlich sowohl foo.c als auch Foo.c anlegen würde. ;-) Einzige Ausnahme: makefile und Makefile, make gibt dabei dem makefile den Vorzug. Kann man nutzen, um temporär eine alternative Datei zu nehmen. Besser ist es aber, make -f newmakefile auszuführen.
Ich soll allen hier am Finden der Ursache beteiligten auch von Eric Weddington nochmals besten Dank aussprechen. Mein persönlicher Dank geht vor allem an Andreas Stephan, den ich beim Einkreisen des Problems förmlich mit Debug-Versionen von GNU make zugeschüttet habe, und der mir geduldig eine Ausgabe nach der anderen zurückgemailt hat.
"Unter Windows ist halt datei.txt und DATEI.TXT (und alle Permutationen davon) dasselbe, während das unter Unix halt nicht der Fall ist." Das doch völliger Quark. NTFS richtet sich hier ganz klar nach POSIX.1 und unterscheidet das sehr wohl. Das die alten Dateisysteme und der Rest vom WinRotz das nicht machen, steht auf einem anderen Blatt...
"Völliger Quark"? Wenn Du Dateisystemzugriffe mit der Win32-API machst, dann liefern CreateFile("datei.txt" ...) und CreateFile("DATEI.TXT" ...) Handles ein und derselben Datei. Wenn Du das alte Posix-Subsystem verwendest (das aus der Zeit vor XP), dann kannst Du mit dafür geschriebenen nicht-Win32-Applikationen unter Verwendung der Posix-Dateizugriffsfunktionen sicherlich Dein quarkfreies Verhalten hinbekommen. Das aber ist nicht der Normalfall. Sicherlich kannst Du Dir auch Interix bzw. die daraus entstandenen Unix-Services for Windows installieren, um eine Posix-Umgebung auf Deinem Windows-System zu erhalten Ich verwende NTFS schon seit etlichen Jahren auf meinen Entwicklungssystemen (bereits vor NT 4.0). Klär' mich auf, wo der Quark zu finden ist
Ich verwende NT auch seit der 3er Version. Deshalb weiss ich das auch und es verhält sich so, wie ich es schreibe. NTFS unterscheidet das, genau wie ich es schrieb, der Rest von Windows nicht, wie ich auch schrieb. Deine Aussage "Unter Windows ist halt datei.txt und DATEI.TXT (und alle Permutationen davon) dasselbe, während das unter Unix halt nicht der Fall ist." ist genau deshalb Quark, weil es eben nicht dasselbe ist, sondern eben unterschiedlich. NTFS und Win32 sind zwei verschieden Dinge. Wenn man möchte, liefert einem NTFS auch die Informationen.
Ich habe nicht behauptet, daß NTFS diese Unterscheidung nicht unterstützen würde - es ist allerdings ziemlich nutzlos, da so gut wie überhaupt keine Software, die unter Windows läuft, damit auch nur irgendetwas anfangen kann. So ist es kontraproduktiv, ein make zu schreiben, das sich unter Windows exakt so verhält, wie unter Unix/Linux, weil sich sonst kein Programm unter Windows an diese nicht-Windows-Konventionen hält. Daher wird es ein Zufallsergebnis sein, ob ein Editor, Compiler oder was auch immer die Dateinamen exakt so interpretiert, wie es eine *nix-nahe make-Portierung machen würde. Es ist also ein Fehler. Auch ist es ein Fehler, davon auszugehen, daß der Anwender zwingend NTFS nutzen muss - für Windows geschriebene Software muss auch mit anderen Dateisystemen klarkommen. Natürlich gibt es hier systemnahe Ausnahmen, Datenbanken, die "sparse files" nutzen wollen, Viren, die "alternate streams" nutzen wollen, andere Software, die sehr große Dateien benötigt, aber für einen Compiler etc. ist die Forderung "geht nur mit NTFS" absolut nicht gerechtfertigt. Im übrigen ist ein schwammiges Statement wie "Wenn man möchte, liefert einem NTFS auch die Informationen." der Diskussion nicht förderlich. "NTFS und Win32 sind zwei verschieden Dinge." Wenn Du Dir nochmal mein Posting zu diesem Thema genau durchläsest (um Dir das Scrollen zu ersparen, zitiere ich mich noch mal) "Unter Windows ist halt datei.txt und DATEI.TXT (und alle Permutationen davon) dasselbe, während das unter Unix halt nicht der Fall ist." könntest Du erkennen, daß ich nirgendwo von NTFS und dessen eher akademisch nutzbaren Fähigkeiten geredet habe. Über den "Unterschied" von NTFS (ein Dateisystem) und Win32 (eine Programmierschnittstelle) müssen wir hier nicht diskutieren.
Hi auch bei FAT (auf jeden Fall mit VFAT) kann ich problemlos Groß- und Kleinschreibung mischen. VFAT verwendet sogar 16 Bit Unicode Zeichen. Matthias
@Matthias: Darum geht es nicht. Sondern darum, ob "meinedatei.txt" eine andere Datei ist als "Meinedatei.txt" oder "MeInEdAtEi.TxT" Unter Windows ist das ein und dieselbe Datei, während das unter *nix drei verschiedene Dateien sind.
Hi das war eher für Joachim gedacht. VFAT kann genauso wie NTFS Groß- und Kleinschreibung unterscheiden. Die Nichtunterscheidung von Groß- und Kleinschreibung ist bei M$ eben auch eine heilige Kuh der Kompatibilität die man nicht zu schlachten bereit ist. Technisch gibt es dafür seit 10 Jahren keinen Grund mehr. Matthias
Hallo Jörg, - aus purer Neugier - wie geht das jetzt weiter - habt ihr eine Patch für make geplant damit es Case-insensitiev wird - oder eher ein Hinwies in die Doku ? Grüße, Stefan PS: Wenn Ihr jetzt noch Sachen im "Release" ändert - wirds dazu "patches" oder "diffs" geben ? und gibts irgendwo eine Änderungs- (bugs - fixed) Historie ?
Keine Ahnung, ich bin beim Bau von WinAVR nicht beteiligt. Ich hatte nur die Gelegenheit genutzt, Eric und Colin hier unter die Arme zu greifen, da sie des Deutschen nicht so recht mächtig sind, sich somit an diesem Thread nicht direkt großartig beteiligen konnten. Ich dachte, dass Eric noch eine Art Announcement schreiben wird. Vielleicht wird er auch eine modifizierte Version von make.exe irgendwo zum Download anbieten. Das Ganze ist letztlich ein Versehen gewesen, wie sich nun herausgestellt hat. Früher hat er GNU make immer explizit so gebaut, dass es case-insensitive für Dateinamen war. Diesmal hat er es nun nicht mehr als Cygwin- sondern als MinGW- Applikation bauen wollen (native Win32, keien Cygwin-DLL mehr nötig), wozu er aus dem MinGW-Projekt Patches hinzuziehen musste. Da war er wohl davon ausgegangen, dass diese Patches auch automatisch die Dateinamengeschichte beinhalten. Da sowohl seine eigenen Tests als auch die bei Colin ganz offenbar kein Durcheinander in der Groß-/ Kleinschreibung der Dateinamen hatten, war ihm das nicht aufgefallen. Andererseits: wenn man einmal darum weiß, ist es ja kein bösartiger Bug. Der Workaround ist simpel: Dateinamen aufräumen, letztlich schafft er ein wenig Ordnung in den Projekten, was ja auch nicht schlecht ist. ;-) Der nette Seiteneffekt: wenn dann mal wieder jemand ein ganzes Projekt hier als zip-Datei postet, weil irgendwas klemmt, wird es auch bei mir funktionieren, ohne dass ich erst die langweilige Arbeit des Dateinamen-Zurechtsortierens für euch machen muss. :-))
Hallo Jörg, ... mit dem "Workaround" kann ich leben :-) Was mich jedoch ein bischen verwirrt hat ist die Aussage von weiter oben im Thread - das paket nochmal herunterzuladen, weil noch Sachen geändert ( gefixt ) wurden. Das fände ich "sauberer" wenn entweder das "release-datum" geändert wuerde - oder ein "patch" veröffentlich wuerde. Grüße, Stefan
Hallo Herr Wunsch, ich habe bisher ohne Probleme mit mit WINAVR auf meinem PC (Win XP) gearbeitet. Beim Umstellen auf die neueste Version 20050214 habe folgendes Problem: Beim Übersetzen eines Projekts mit MAKE ALL aus dem PN heraus, erhalte ich von Windows folgende Meldung: avr-gcc.exe: Es befindet sich kein Datenträger im Laufwerk. Legen Sie einen Datenträger in Laufwerk \Device\Harddisk4\DR8 ein. Ich habe darauf die Pfadangaben in der Registry untersucht, die sind korrekt. Was mich stutzig macht ist, die Laufwerksangabe, die gibts bei mir gar nicht. Vielleicht können Sie mir einen Tip geben. Mit freundlichen Grüßen N. Dehn
Mal von www.sysinternals.com den Filemon 'runterladen, dann kann man 'rausfinden, auf was für eine Datei mit was für einem Pfad da jemand versucht, zuzugreifen.
Danke für die Infos. Ich habe mal weiter geforscht. Das Projekt wird dann sauber abgearbeitet wenn man in der Dialogbox "Eigenschaften von Edit Tool" (zu finden unter "Tools -> Options -> Tools -> Edit Make all") im Editfeld "Folder" den direkten Pfad zum Projekt einträgt. Das würde bedeuten, dass im anderen Fall der Pfad auf das Projekt nicht in Ordnung ist. Ich habe diese Version von WinAvr zum Test auch auf 2 weiteren Pc's mit Win XP, bzw. Win 2K installiert. Beide Installationen arbeiten einwandfrei. Vielleicht hat jemand eine Idee. Mit freundlichen Grüßen N. Dehn
Hallo Matthias, hallo Rufus, Euere Beiträge haben mir sehr geholfen. Der Fehler lag an einem, am USB-Port angeschlossener "6 in 1 Card Reader". Nach entfernen dieses Gerätes läuft alles einwandfrei. Besten Dank N. Dehn
Hallo, der Fehler mit dem fehlenden Laufwerk / Medien ist aber nicht neu. Das gab es schon in der vorherigen Version und dort trat es bei mir auch immer in Verbindung mit diversen USB Laufwerken (Card Reader, USB Sticks) auf... Vielleicht lässt sich der Fehler ja mal ergründen.
Wie ich bereits andeutete, mit FileMon besteht die Chance, herauszufinden, auf was für eine Datei da zugegriffen wird. Mit deren vollständigen Namen könnte man sicherlich einen der Entwickler beglücken.
Nö, nicht so sehr. Der GCC hat halt in seinen Specs das aktuelle Verzeichnis, auf dem er gebaut worden ist, in include- und lib-Path mit reincompiliert. Früher hat Eric wohl auf Laufwerk E: gebaut, mittlerweile hat er extra dafür M: genommen (glaub' ich). Bei der Suche nach Header- oder Bibliotheksdateien rennt er dann da drüber. Da passiert so lange nichts dabei, wie das auf ein ungültiges Laufwerk zeigt, dann wird das einfach ignoriert. Trifft er aber auf ein Laufwerk, das Windows kennt und ein Wechselmedium hat, dann ruft irgendwer danach, dass er ebendieses Wechselmedium zu sehen bekommt... Zumindest ist das der Vorgang, wie ich ihn verstanden habe.
Ist das nicht etwas, nun, fragwürdig? Die Verwendung relativer Pfade (relativ zum Ort der .exe-Datei) wäre IMHO sinnvoller.
Der GCC ist aber kein Windows-Programm. Damit du das bekommst, müsstest du ihn auf dem Zielsystem mit den dort aktuellen Pfaden konfigurieren und compilieren. Unter Unix ist diese mal-hierhin- mal-dahin-Schieberei im Filesystem wie bei Windows nicht üblich. Man konfiguriert es für einen Präfix von /usr oder /usr/local, fertig die Laube. Dadurch hat GCC eben keine Vorkehrungen, dass man das noch beim Installieren modifizieren kann.
Gut, starten wir keine philosophische Diskussion. Prinzipiell sollte auch ein *nix-Programm mit relativen Pfaden arbeiten können, aber das scheint dann im Grunddesign des GCC halt nicht so angelegt zu sein. Allenfalls könnte man bei der Portierung nach Windows darauf achten, daß keine absoluten Pfade verwendet werden ... oder aber den Weg des geringsten Widerstandes gehen und damit leben, daß das Teil sich verhält, wie es das nun mal tut.
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.