Probleme mit dem Visual C++ Compiler (glaub ich)
- Ersteller Cybered
- Erstellt am
Cybered
Admiral Special
Ich wollte gerade ein kleines Programm für mein neues Spielzeug (VIA C7 mit Padlock Engine) kompilieren. Hab jetzt mit dem Guide von VIA folgendes programm erstellt ->
Ich hab das mit Visual Studio Express Edition kompiliert. Auf dem rechner wo ich es erstellt habe, läuft es auch...allerdings ist da ein Athlon drin, der natürlich kein Padlock hat. Wenn ich die kompilierte Exe Datei dann aber auf den Zielrechner (der hat ne VIA CPU 
) kopiere, sagt der immer, das die Anwendung nicht gestartet werden kann. Hab auch schon die dll bzw. die .lib mitkopiert, aber ohne Erfolg.
thx4all
Cybered
Code:
// Program für VIA Padlock
#include "padlock.h"
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int rng_available = padlock_rng_available();
if (rng_available==0)
{
printf("RNG nicht da");
return -1;
}
else
{
printf("RNG ist da");
return -1;
}
}thx4all
Cybered
Hmm das kann alles mögliche sein.
1. Nur als Hinweis: Bei beiden Pfaden kommt -1 zurück.
2. Sind die Kompiliereinstellungen kompatibel zu der Via-CPU? Also z.B. kein 64-Bit-Binary?
3. Linkst du statisch oder dynamisch? Im Falle ersteres musst du nichts kopieren, in letzterm Fall muss die DLL im selben Verzeichnis wie die Exe liegen.
4. Fehlt die msvcrt auf dem Via-Rechner? Entweder nachinstallieren, oder MFC-Bibliotheken (so ähnlich heisst die Option) auch auf statisch setzen.
Was genau ist denn die Fehlermeldung?
Weitere fehlende DLLs kannst du auch mit DependencyWalker herausfinden.
1. Nur als Hinweis: Bei beiden Pfaden kommt -1 zurück.
2. Sind die Kompiliereinstellungen kompatibel zu der Via-CPU? Also z.B. kein 64-Bit-Binary?
3. Linkst du statisch oder dynamisch? Im Falle ersteres musst du nichts kopieren, in letzterm Fall muss die DLL im selben Verzeichnis wie die Exe liegen.
4. Fehlt die msvcrt auf dem Via-Rechner? Entweder nachinstallieren, oder MFC-Bibliotheken (so ähnlich heisst die Option) auch auf statisch setzen.
Was genau ist denn die Fehlermeldung?
Weitere fehlende DLLs kannst du auch mit DependencyWalker herausfinden.
Nachtschicht
Admiral Special
Womöglich wurde das Programm als managed Code (für .NET) gebaut, da hilft dann eine .NET Installation.
Fehlende MFC-Bibliotheken dürften nicht die Ursache sein, da der Quellcode komplett MFC-frei ist.
Fehlende MFC-Bibliotheken dürften nicht die Ursache sein, da der Quellcode komplett MFC-frei ist.
Cybered
Admiral Special
Oh je,
das sind zeimlich viele Infos auf einmal..ist übrigens mein erstes C++ Programm, hatte ne Zeitlang mit Java zu tun, da war das irgendwie einfacher *duckundwegrenn*
Werde mich mal mit den einzelnen Punkten befassen, aber es kann doch wohl nicht so schwer sein einen Quellcode zu schreiben, den zu kompilieren (was beim Visual Studio auch nicht geklappt hat, mußte über Debug gehen um ne Exe zu bekommen
*) und dann hab ich eine Exe und die läuft dann...
schon mal danke für die Infos und habt ihr an Weihnachten nix besseres zu tun *haha*
Cybered
das sind zeimlich viele Infos auf einmal..ist übrigens mein erstes C++ Programm, hatte ne Zeitlang mit Java zu tun, da war das irgendwie einfacher *duckundwegrenn*
Werde mich mal mit den einzelnen Punkten befassen, aber es kann doch wohl nicht so schwer sein einen Quellcode zu schreiben, den zu kompilieren (was beim Visual Studio auch nicht geklappt hat, mußte über Debug gehen um ne Exe zu bekommen
*) und dann hab ich eine Exe und die läuft dann...schon mal danke für die Infos und habt ihr an Weihnachten nix besseres zu tun *haha*
Cybered
Man sollte halt mal das Manual lesen, wenn man Visual Studio nicht bedienen kann.aber es kann doch wohl nicht so schwer sein einen Quellcode zu schreiben, den zu kompilieren (was beim Visual Studio auch nicht geklappt hat, mußte über Debug gehen um ne Exe zu bekommen
Eine Debug-Version solltest du übrigens nicht unbedingt ausliefern (langsam, braucht spezielle DLLs).Höchst unwahrscheinlich. Visual C++ nutzt standardmäßig kein .net. Außerdem wäre die Fehlermeldung dann eine andere glaube ich.
Ob du es nutzt oder nicht, interessiert den Linker nicht wirklich und wenn der Linker MFC mit reinnimmt (weil er so konfiguriert ist), brauchst du die DLLs. Aber MFC ist definitiv nicht dein Problem, denn Visual C++ Express Edition hat gar kein MFC dabei.
Dein Problem ist die Visual C++ Runtime (MSVCRT). Entweder du linkst die statisch oder du musst auf dem Zielrechner die Visual C++ Runtime installieren.
Jo sag ich doch.
Bei VS 2005 heisst die Option dann "MFC in einer statischen Bibliothek verwenden" oder so ähnlich.Kann bei 2008 natürlich wieder anders sein.
*gnar* Ich weiss, dass das was anderes ist, aber ich bin mir (relativ) sicher, dass die Option so heisst (zumindest bei 2005).
Ich kann am Montag mal nen Screenshot machen.
edit: Was man nicht alles findet: http://www.kalmbach-software.de/screencasts/VC2008EE-StaticLinkCRT/
Sogar auf deutsch.
Dass es diese Option gab war mir zwar bewusst, aber ... hmm, da muss ich nochmal nen kleinen Test machen. Bei mir war es immer die MFC-Option, die letztendlich die CRT-DLL verbannt hat (auch ohne MFC-Code).
Ich kann am Montag mal nen Screenshot machen.
edit: Was man nicht alles findet: http://www.kalmbach-software.de/screencasts/VC2008EE-StaticLinkCRT/
Sogar auf deutsch.
Dass es diese Option gab war mir zwar bewusst, aber ... hmm, da muss ich nochmal nen kleinen Test machen. Bei mir war es immer die MFC-Option, die letztendlich die CRT-DLL verbannt hat (auch ohne MFC-Code).
Zuletzt bearbeitet:
Cybered
Admiral Special
So, hab nun die MFC Option geändert -> MFC in einer Statischen Bibliothek verwenden
Danach war die erzeugte Exe zwar anstatt 30kB jetzt ~450kB groß, läuft jetzt aber auf dem "Zielsystem"...
Danke ...
Cybered
Danach war die erzeugte Exe zwar anstatt 30kB jetzt ~450kB groß, läuft jetzt aber auf dem "Zielsystem"...
Danke ...
Cybered
Wahrscheinlich impliziert die MFC-Option auch das statische Linken der CRT, das würde das ganze erklären.
Der Anstieg auf die 15-fache Größe ist aber ziemlich krass - hast du den Build auf "Release" gestellt?
Meine Konsolen-Programme kommen eigentlich nie über 150 KB und da ist dann meist noch n Haufen anderes Zeug drin.
Der Anstieg auf die 15-fache Größe ist aber ziemlich krass - hast du den Build auf "Release" gestellt?
Meine Konsolen-Programme kommen eigentlich nie über 150 KB und da ist dann meist noch n Haufen anderes Zeug drin.
Cybered
Admiral Special
Kein Ahnung ob ich den Build auf Release gestellt hab 
Bei VIA gibts nen JCP (Java Crypto Service Provider), der fungiert als Art Zwischenschicht, die sämtliche Aufrufe von Kryptografiefunktionen und Zufallszahlen in Java Programmen abfängt und dann in Hardware vom Prozessor abarbeiten lässt...
Ich werde die Sache wohl von der Seite aus angehen...da ich wie gesagt mal ne Zeitlang mit Java und einer für mich ausreichenden IDE verbracht habe...denn die zeit, mich in die C++ inkl. IDE Umgebung einzuarbeiten, kann ich auch direkt mit dem Projekt verbringen...man muß ja nicht auf 2 Hochzeiten tanzen
Cybered
Bei VIA gibts nen JCP (Java Crypto Service Provider), der fungiert als Art Zwischenschicht, die sämtliche Aufrufe von Kryptografiefunktionen und Zufallszahlen in Java Programmen abfängt und dann in Hardware vom Prozessor abarbeiten lässt...
Ich werde die Sache wohl von der Seite aus angehen...da ich wie gesagt mal ne Zeitlang mit Java und einer für mich ausreichenden IDE verbracht habe...denn die zeit, mich in die C++ inkl. IDE Umgebung einzuarbeiten, kann ich auch direkt mit dem Projekt verbringen...man muß ja nicht auf 2 Hochzeiten tanzen
Cybered
BoMbY
Grand Admiral Special
Mit dieser Option werden vermutlich die benötigten DLLs/Libs/Whatever einfach mit in die EXE-Datei gepackt. Wie zum Beispiel früher bei Delphi. Das jedenfalls würde die Größe erklären. Wenn ich das richtig sehe, ist dies auch der von Microsoft empfohlene Weg, um Konflikte auf dem Zielsystem zu vermeiden.
Wenn die Dateigröße auf dem Zielsystem kritisch ist, würde ich mal einen Blick auf UPX werfen.
Woerns
Grand Admiral Special
- Mitglied seit
- 05.02.2003
- Beiträge
- 2.983
- Renomée
- 232
Auch wenn das Problem wohl schon gelöst ist, hier ein Tipp für all diejenigen, die in ähnlichen Schwierigkeiten stecken:
In der Entwicklerumgebung von Microsoft Visual Studio 2005 gibt es ein Tool namens Depends.exe, das unter einem ähnlichen Pfad wie diesem hier liegt:
C:\Programme\Microsoft Visual Studio 8\Common7\Tools\Bin\Depends.Exe
Man startet Depends.exe und lässt das Programm, das nicht laufen will, vom Explorer aus auf dessen Oberfläche fallen. Dann werden alle Abhängigkeiten von MFC- und System-DLLs aufgelistet, wobei angezeigt wird, ob die entsprechende DLL verfügbar ist. Darüber hinaus wird angezeigt, ob es sich um Debug- oder Release-Versionen handelt.
Im vorliegenden Fall kann man einfach das Programm Depends.exe mit auf den VIA Rechner nehmen und dort starten. Es benötigt meines Wissens keine weiteren Komponenten. Inwieweit das Portieren mit der Lizenz für das Visual Studio vereinbar ist, weiß ich allerdings nicht, aber man kann es nach seinem Test ja einfach wieder löschen.
MfG
In der Entwicklerumgebung von Microsoft Visual Studio 2005 gibt es ein Tool namens Depends.exe, das unter einem ähnlichen Pfad wie diesem hier liegt:
C:\Programme\Microsoft Visual Studio 8\Common7\Tools\Bin\Depends.Exe
Man startet Depends.exe und lässt das Programm, das nicht laufen will, vom Explorer aus auf dessen Oberfläche fallen. Dann werden alle Abhängigkeiten von MFC- und System-DLLs aufgelistet, wobei angezeigt wird, ob die entsprechende DLL verfügbar ist. Darüber hinaus wird angezeigt, ob es sich um Debug- oder Release-Versionen handelt.
Im vorliegenden Fall kann man einfach das Programm Depends.exe mit auf den VIA Rechner nehmen und dort starten. Es benötigt meines Wissens keine weiteren Komponenten. Inwieweit das Portieren mit der Lizenz für das Visual Studio vereinbar ist, weiß ich allerdings nicht, aber man kann es nach seinem Test ja einfach wieder löschen.
MfG
