Forum: Compiler & IDEs WinAVR 20050214 herausgegeben


von Jörg Wunsch (Gast)


Lesenswert?

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

von Andreas Stephan (Gast)


Lesenswert?

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

von Jörg Wunsch (Gast)


Lesenswert?

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

von Andreas Stephan (Gast)


Lesenswert?

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

von Jörg Wunsch (Gast)


Lesenswert?

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

von Andreas Stephan (Gast)


Angehängte Dateien:

Lesenswert?

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

von Jörg Wunsch (Gast)


Lesenswert?

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

von Andreas Stephan (Gast)


Lesenswert?

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

von Jörg Wunsch (Gast)


Lesenswert?

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.

von Andreas Stephan (Gast)


Lesenswert?

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

von Jörg Wunsch (Gast)


Lesenswert?

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.

von Andreas Stephan (Gast)


Angehängte Dateien:

Lesenswert?

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

von Andreas Stephan (Gast)


Angehängte Dateien:

Lesenswert?

Jörg, falls Du das MAKEFILE noch beschauen willst....

Bitte schön

73, Andreas

von Jörg Wunsch (Gast)


Lesenswert?

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.

von Jörg Wunsch (Gast)


Lesenswert?

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.

von Andreas Stephan (Gast)


Angehängte Dateien:

Lesenswert?

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

von Andreas Stephan (Gast)


Angehängte Dateien:

Lesenswert?

Und dazu noch das MAKEFILE,
Warum kann man eigentlich nicht mehrere File uploaden ?!

von Jörg Wunsch (Gast)


Lesenswert?

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

von peter dannegger (Gast)


Lesenswert?

"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

von Jörg Wunsch (Gast)


Lesenswert?

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

von Andreas Stephan (Gast)


Lesenswert?

Jörg,
OK, machen wir mal direkt weiter.....

von Dirk (Gast)


Lesenswert?

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

von Jörg Wunsch (Gast)


Lesenswert?

FAT-Filesystem?

von Dirk (Gast)


Lesenswert?

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

von Dirk (Gast)


Lesenswert?

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

von Hagen (Gast)


Lesenswert?

ö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

von mthomas (Gast)


Lesenswert?

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

von Rufus T. Firefly (Gast)


Lesenswert?

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.

von Jörg Wunsch (Gast)


Lesenswert?

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.

von Jörg Wunsch (Gast)


Lesenswert?

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

von Rufus T. Firefly (Gast)


Lesenswert?

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.

von Jörg Wunsch (Gast)


Lesenswert?

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.

von Jörg Wunsch (Gast)


Lesenswert?

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.

von Joachim (Gast)


Lesenswert?

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

von Rufus T. Firefly (Gast)


Lesenswert?

"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

von Joachim (Gast)


Lesenswert?

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.

von Rufus T. Firefly (Gast)


Lesenswert?

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.

von Matthias (Gast)


Lesenswert?

Hi

auch bei FAT (auf jeden Fall mit VFAT) kann ich problemlos Groß- und
Kleinschreibung mischen. VFAT verwendet sogar 16 Bit Unicode Zeichen.

Matthias

von Rufus T. Firefly (Gast)


Lesenswert?

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

von Matthias (Gast)


Lesenswert?

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

von Stefan.Sczekalla (Gast)


Lesenswert?

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 ?

von Jörg Wunsch (Gast)


Lesenswert?

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

von Stefan Sczekalla (Gast)


Lesenswert?

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

von Norbert Dehn (Gast)


Lesenswert?

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

von Matthias (Gast)


Lesenswert?

Hi

einfach mal in alle CD-Laufwerke ein CD einlegen.

Matthias

von Rufus T. Firefly (Gast)


Lesenswert?

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.

von Norbert Dehn (Gast)


Lesenswert?

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

von Norbert Dehn (Gast)


Lesenswert?

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

von Dirk (Gast)


Lesenswert?

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.

von Rufus T. Firefly (Gast)


Lesenswert?

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.

von Jörg Wunsch (Gast)


Lesenswert?

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.

von Rufus T. Firefly (Gast)


Lesenswert?

Ist das nicht etwas, nun, fragwürdig? Die Verwendung relativer Pfade
(relativ zum Ort der .exe-Datei) wäre IMHO sinnvoller.

von Jörg Wunsch (Gast)


Lesenswert?

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.

von Rufus T. Firefly (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.