Sieht aus wie ein Rechteproblem, ist es aber nicht!
Die Ausführung in einer DOS-Shell bringt folgende Meldung zutage:
1
d:\tmp\binutils\exe>avr-objdump.exe
2
Die Version von d:\tmp\binutils\exe\avr-objdump.exe ist nicht mit der
3
ausgeführten Windows-Version kompatibel. Öffnen Sie die Systeminformationen
4
des Computers, um zu überprüfen, ob eine x86-(32 Bit)- oder eine x64-(64
5
Bit)-Version des Programms erforderlich ist, und wenden Sie sich
6
anschließend an den Herausgeber der Software.
Offensichtlich handelt es sich um eine 16Bit-Anwendung, die von Windows
7 nicht mehr unterstützt wird.
Leider schaffe ich es nicht, die binutils zu übersetzen, Google hat auch
keine passende Lösung.
Hat vielleicht jemand eine funktionierende Datei für mich? Oder einen
Workaround? Ab und zu muss man mal in die erzeugte .lss-Datei
reinsehen...
Peter K. schrieb:> Sieht aus wie ein Rechteproblem, ist es aber nicht!
Ja, das kann gut möglich sein, leider gibt es in vielen
Windows-Softwarestacks die Tendenz, alle nicht "erklärlichen" Fehler auf
Rechteprobleme abzuschieben. Das stammt aus der Zeit, als es für viele
Windows-Programmierer erstmals nötig wurde, sich mit Programmfehlern
auseinanderzusetzen, die auf mangelnde Benutzerrechte zurückgehen. Das
war allerdings so um das Jahr 2002 herum, nicht mehr 2010, aus dem deine
binutils wohl stammen...
> Die Ausführung in einer DOS-Shell bringt folgende Meldung zutage:>
1
d:\tmp\binutils\exe>avr-objdump.exe
2
> Die Version von d:\tmp\binutils\exe\avr-objdump.exe ist nicht mit der
3
> ausgeführten Windows-Version kompatibel. Öffnen Sie die
4
> Systeminformationen
5
> des Computers, um zu überprüfen, ob eine x86-(32 Bit)- oder eine x64-(64
6
> Bit)-Version des Programms erforderlich ist, und wenden Sie sich
7
> anschließend an den Herausgeber der Software.
>> Offensichtlich handelt es sich um eine 16Bit-Anwendung, die von Windows> 7 nicht mehr unterstützt wird.
Hmm... Das finde ich jetzt nicht so ganz offensichtlich. Was genau
bewegt dich zu glauben, daß avr-objdump.exe eine Win16-Anwendung wäre?
Die Fehlermeldung gibt einen solchen Schluß jedenfalls keinesfalls her.
Mal ganz abgesehen davon ist es auch relativ unglaubhaft, daß 2010 noch
irgendwas an freier Software für Win16 kompiliert worden sein könnte. Wo
sollte da der Sinn liegen, es war doch zu der Zeit schon lange um vieles
einfacher war, für Win32 zu kompilieren und auch schon lange kein
Schwein mehr Win16 eingesetzt hat?
Nein, alles Quatsch, was du schreibst. Höchstwahrwscheinlich stimmt nur
irgendwas mit dem Pfad nicht mehr und avr-objdump.exe findet deswegen
irgendeine Abhängigkeit nicht mehr als als Win32-DLL vor, sondern zuerst
als Win64-DLL.
Vermutlich nur irgendwas neueres drüberinstalliert, was den Pfad
geändert hat.
Allerdings: Die Evolution von Windows ist immerhin inzwischen auch
soweit gediehen, daß man NIEMALS mehr in einer unauflösbaren Situation
bezüglich der Abhängigkeiten landen kann. Das Problem ist also in jedem
Fall lösbar.
Folge dem Pfad...
Hallo c-hater,
tatsächlich setze ich die neueste WinAVR-20100110 (lach) ein.
> Hmm... Das finde ich jetzt nicht so ganz offensichtlich. Was genau> bewegt dich zu glauben, daß avr-objdump.exe eine Win16-Anwendung wäre?
Das sieht man im Fensterkopf des beigelegten Bildes. Dieses Fenster
poppt auch auf wenn ich das Programm in der Shell starte.
> Höchstwahrwscheinlich stimmt nur> irgendwas mit dem Pfad nicht mehr und avr-objdump.exe findet deswegen> irgendeine Abhängigkeit nicht mehr als als Win32-DLL vor, sondern zuerst> als Win64-DLL.
Hmm... das glaube ich nicht. Die binutils werden unter Linux bzw. cygwin
oder MinGW kompiliert. Woher sollen die etwas von irgendwelchen Win-DLLs
wissen? Und avr-objcopy.exe läuft anstandslos, das kommt aus demselben
Paket.
> Folge dem Pfad...
Ich bin ziemlich verzweifelt und greife nach jedem Strohhalm. Welchem
Pfad sollte ich deiner Meinung nach folgen?
Peter K. schrieb:> Das sieht man im Fensterkopf des beigelegten Bildes.
Wen du glaubst, daß Fehlermeldungen immer sinnvolle Anzeigen liefern,
glaubst du vermutlich auch noch, daß der Klapperstorch die Babies
liefert...
> Hmm... das glaube ich nicht. Die binutils werden unter Linux bzw. cygwin> oder MinGW kompiliert. Woher sollen die etwas von irgendwelchen Win-DLLs> wissen?
Weil sie nach dem Compilieren schlicht nichts mehr davon wissen, wie sie
mal compiliert wurden. Dann sind's nur noch Win-Executables, die sich
verhalten wie alle anderen Win-Executables auch. D.h. insbesondere: sie
suchen sich ihre DLL-Abhängigkeiten nach demselben Schema wie alle
anderen Win-Executables auch. Und dieses Schema ist recht variabel,
wobei der Pfad eine wichtige Rolle spielt, denn jedes dort aufgeführte
Verzeichnis ist ein potentieller DLL-Beherberger.
> Und avr-objcopy.exe läuft anstandslos, das kommt aus demselben> Paket.
Dann vergleich doch einfach mal die Abhängigkeiten der beiden Programme,
z.B. mit depends.exe. Wetten, daß es Unterscheide gibt? Und wetten, daß
mindestens eine der DLLs, die zwar von avr-objdump, aber nicht von
avr-objcopy genutzt wird, mehrfach in deinem Pfad auftaucht?
> verzweifelt und greife nach jedem Strohhalm. Welchem> Pfad sollte ich deiner Meinung nach folgen?
Oh Gott... Du weißt wirklich nicht, was DER Pfad ist?
Nunja, schlage das einfach mit google nach. Ich habe kein Lust dazu, dir
das zu erklären. Nur soviel: Anzeigen lassen kannst du dir ihn mittels
einer Console (AKA: "DOS-Box", "Eingabeaufforderung" oder wie auch
immer). Das Kommando dazu heißt: set path
Hallo c-hater,
> Wen du glaubst, daß Fehlermeldungen immer sinnvolle Anzeigen liefern,> glaubst du vermutlich auch noch, daß der Klapperstorch die Babies> liefert...
Wie? Geht das auch anders?
Scherz beiseite ;)
Ich habe mir den Dependency Walker geladen. Seine Meinung ist:
No DOS or PE signature found. This file ist not a 32-bit or 64-bit
Windows module.
Mag sein, dass die Datei irgendwelchen Schaden genommen hat. Daher habe
ich das komplette WinAVR-Paket nochmals installiert. Das Ergebnis ist
dasselbe. Natürlich habe ich auch die Prüfsumme mit der bei
sourceforge.net verglichen. Kein Unterschied.
Und nun?
Gibt es niemanden, der dieses Programm erfolgreich einsetzt? Das wird
unter Eclipse doch auch aufgerufen...
> Gibt es niemanden, der dieses Programm erfolgreich einsetzt?
Doch, aber bei allen anderen gehts(tm), nur bei Dir nicht. Zeig doch mal
das Executable her.
Hallo g457,
das ist sehr seltsam und auch hilfreich. Entweder habe ich "nette" Gäste
auf meinem PC oder die SSD zickt. Aber dies ist wirklich das erste Mal,
dass ich solche Probleme habe. Mein letzter Virus ist gut und gerne 35
Jahre her...
Vielen Dank für die Analyse, denn darauf bin ich nicht gekommen.
@bluppdidupp
der Tipp war Gold wert!
Toolchain geladen, mit 7z geöffnet und die Datei ersetzt.
Funktioniert einwandfrei.
Ich möchte mich bei allen Beteiligten für die Hilfe bedanken.
Thread beobachten
Seitenaufteilung abschalten