Je suis nouveau sur ce forum et je m'excuse par avance si ma question a
déjà été traitée.
Je me suis entrainé à faire une application console en C puis j'ai
refait la même en C++.
J'ai utilisé pour cela visual c++ sous windows.
Quand j'ai voulu utiliser mon executable C sur des "postes utilisateurs"
sans outil de développement. Je n'ai pas rencontré de problème.
Par contre, lorsque j'ai voulu faire la même chose avec mon executable
C++, j'ai obtenu un message d'erreur.
En cherchant, j'ai trouvé que l'on devait déjà utiliser le mode release
et pas le mode debug.
Jusque là je peux comprendre.
Par contre, il faut aussi installer sur les postes utilisateurs qui
n'ont pas Visual c++, le package redistribuable microsoft pour que cela
fonctionne.
Seulement, si j'ai trouvé la solution au problème, j'ai quelques
interrogations à ce sujet.
Je pensais qu'une fois le C ou le C++ compilé, on obtenait du code
"natif". Ce que je comprends comme pouvant être compris directement par
la machine. Comme ce fait-il que visual C++ ne me permette pas d'obtenir
un executable "autonome" ?
Est-ce possible de créer un exe qui se suffise à lui-même si je puis
dire ? Comment ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sylvain Togni
psykzix a écrit :
Est-ce propre à visual C++ et/ou à windows ?
Pas spécialement, la problématique est plus ou moins la même sur les autres compilateurs / OS.
C'est un problème de déploiement. Il faut s'assurer de bien déployer tous les fichiers nécessaires au fonctionnement de l'exécutable. Notamment, les bibliothèques standard C et C++ si elles sont utilisée dynamiquement.
Sous Visual C++, la bibliothèque standard C c'est le fichier MSVCRT.dll. Celui-là, je crois, est installé par Windows, d'où l'absence de problème. La version C++ par contre c'est un fichier MSVCPxx.dll qu'il faut déployer sur la machine cible.
Mais le plus simple est d'indiquer au linker d'utiliser les bibliothèques statiquement (Properties/C/C++/Code Generation/Runtime Library/ Multi-threaded), ça fait un exécutable un peu plus gros (mais moins que l'exe + la DLL), et comme ça pas d'emmerdes.
-- Sylvain Togni
psykzix a écrit :
Est-ce propre à visual C++ et/ou à windows ?
Pas spécialement, la problématique est plus ou moins la même sur
les autres compilateurs / OS.
C'est un problème de déploiement. Il faut s'assurer de bien déployer
tous les fichiers nécessaires au fonctionnement de l'exécutable.
Notamment, les bibliothèques standard C et C++ si elles sont utilisée
dynamiquement.
Sous Visual C++, la bibliothèque standard C c'est le fichier MSVCRT.dll.
Celui-là, je crois, est installé par Windows, d'où l'absence de problème.
La version C++ par contre c'est un fichier MSVCPxx.dll qu'il faut
déployer sur la machine cible.
Mais le plus simple est d'indiquer au linker d'utiliser les bibliothèques
statiquement (Properties/C/C++/Code Generation/Runtime Library/
Multi-threaded), ça fait un exécutable un peu plus gros (mais moins que
l'exe + la DLL), et comme ça pas d'emmerdes.
Pas spécialement, la problématique est plus ou moins la même sur les autres compilateurs / OS.
C'est un problème de déploiement. Il faut s'assurer de bien déployer tous les fichiers nécessaires au fonctionnement de l'exécutable. Notamment, les bibliothèques standard C et C++ si elles sont utilisée dynamiquement.
Sous Visual C++, la bibliothèque standard C c'est le fichier MSVCRT.dll. Celui-là, je crois, est installé par Windows, d'où l'absence de problème. La version C++ par contre c'est un fichier MSVCPxx.dll qu'il faut déployer sur la machine cible.
Mais le plus simple est d'indiquer au linker d'utiliser les bibliothèques statiquement (Properties/C/C++/Code Generation/Runtime Library/ Multi-threaded), ça fait un exécutable un peu plus gros (mais moins que l'exe + la DLL), et comme ça pas d'emmerdes.
-- Sylvain Togni
psykzix
Sylvain Togni a écrit :
psykzix a écrit :
Est-ce propre à visual C++ et/ou à windows ?
Pas spécialement, la problématique est plus ou moins la même sur les autres compilateurs / OS.
C'est un problème de déploiement. Il faut s'assurer de bien déployer tous les fichiers nécessaires au fonctionnement de l'exécutable. Notamment, les bibliothèques standard C et C++ si elles sont utilisée dynamiquement.
Sous Visual C++, la bibliothèque standard C c'est le fichier MSVCRT.dll. Celui-là, je crois, est installé par Windows, d'où l'absence de problème. La version C++ par contre c'est un fichier MSVCPxx.dll qu'il faut déployer sur la machine cible.
Mais le plus simple est d'indiquer au linker d'utiliser les bibliothèques statiquement (Properties/C/C++/Code Generation/Runtime Library/ Multi-threaded), ça fait un exécutable un peu plus gros (mais moins que l'exe + la DLL), et comme ça pas d'emmerdes.
Bonjour Je te remercie pour ta réponse. J'ai effectivement réussi à faire un exe autonome avec l'option Multi-thread plutôt que DLL Multi-thread.
Sylvain Togni a écrit :
psykzix a écrit :
Est-ce propre à visual C++ et/ou à windows ?
Pas spécialement, la problématique est plus ou moins la même sur
les autres compilateurs / OS.
C'est un problème de déploiement. Il faut s'assurer de bien déployer
tous les fichiers nécessaires au fonctionnement de l'exécutable.
Notamment, les bibliothèques standard C et C++ si elles sont utilisée
dynamiquement.
Sous Visual C++, la bibliothèque standard C c'est le fichier MSVCRT.dll.
Celui-là, je crois, est installé par Windows, d'où l'absence de problème.
La version C++ par contre c'est un fichier MSVCPxx.dll qu'il faut
déployer sur la machine cible.
Mais le plus simple est d'indiquer au linker d'utiliser les bibliothèques
statiquement (Properties/C/C++/Code Generation/Runtime Library/
Multi-threaded), ça fait un exécutable un peu plus gros (mais moins que
l'exe + la DLL), et comme ça pas d'emmerdes.
Bonjour
Je te remercie pour ta réponse.
J'ai effectivement réussi à faire un exe autonome avec l'option
Multi-thread plutôt que DLL Multi-thread.
Pas spécialement, la problématique est plus ou moins la même sur les autres compilateurs / OS.
C'est un problème de déploiement. Il faut s'assurer de bien déployer tous les fichiers nécessaires au fonctionnement de l'exécutable. Notamment, les bibliothèques standard C et C++ si elles sont utilisée dynamiquement.
Sous Visual C++, la bibliothèque standard C c'est le fichier MSVCRT.dll. Celui-là, je crois, est installé par Windows, d'où l'absence de problème. La version C++ par contre c'est un fichier MSVCPxx.dll qu'il faut déployer sur la machine cible.
Mais le plus simple est d'indiquer au linker d'utiliser les bibliothèques statiquement (Properties/C/C++/Code Generation/Runtime Library/ Multi-threaded), ça fait un exécutable un peu plus gros (mais moins que l'exe + la DLL), et comme ça pas d'emmerdes.
Bonjour Je te remercie pour ta réponse. J'ai effectivement réussi à faire un exe autonome avec l'option Multi-thread plutôt que DLL Multi-thread.
Fabien LE LEZ
On Fri, 27 Feb 2009 12:21:22 +0100, Sylvain Togni <"sylvain.togni at visionobjects.com">:
La version C++ par contre c'est un fichier MSVCPxx.dll qu'il faut déployer sur la machine cible.
C'est plus compliqué que ça.
Pour qu'un exécutable compilé avec VC++ 2008 fonctionne sous Windows 2000, il faut que msvcm90.dll, msvcr90.dll et msvcp90.dll soient dans le même répertoire que l'exécutable. Pour que le même exécutable fonctionne sous Windows XP, il faut que ces trois fichiers, avec en plus un fichier Microsoft.VC90.CRT.manifest, soient dans un sous-répertoire appelé Microsoft.VC90.CRT.
Du coup, on se retrouve à recopier deux fois ces fichiers.
Mais le plus simple est d'indiquer au linker d'utiliser les bibliothèques statiquement (Properties/C/C++/Code Generation/Runtime Library/ Multi-threaded), ça fait un exécutable un peu plus gros (mais moins que l'exe + la DLL), et comme ça pas d'emmerdes.
Oui. J'ai toutefois vite eu des soucis quand j'ai voulu découper un projet en plusieurs morceaux (.lib je crois) : les bibliothèques statiques de VC++ étaient incluses plusieurs fois, et le link plantait.
On Fri, 27 Feb 2009 12:21:22 +0100, Sylvain Togni <"sylvain.togni at
visionobjects.com">:
La version C++ par contre c'est un fichier MSVCPxx.dll qu'il faut
déployer sur la machine cible.
C'est plus compliqué que ça.
Pour qu'un exécutable compilé avec VC++ 2008 fonctionne sous
Windows 2000, il faut que msvcm90.dll, msvcr90.dll et msvcp90.dll
soient dans le même répertoire que l'exécutable.
Pour que le même exécutable fonctionne sous Windows XP, il faut que
ces trois fichiers, avec en plus un fichier
Microsoft.VC90.CRT.manifest, soient dans un sous-répertoire appelé
Microsoft.VC90.CRT.
Du coup, on se retrouve à recopier deux fois ces fichiers.
Mais le plus simple est d'indiquer au linker d'utiliser les bibliothèques
statiquement (Properties/C/C++/Code Generation/Runtime Library/
Multi-threaded), ça fait un exécutable un peu plus gros (mais moins que
l'exe + la DLL), et comme ça pas d'emmerdes.
Oui. J'ai toutefois vite eu des soucis quand j'ai voulu découper un
projet en plusieurs morceaux (.lib je crois) : les bibliothèques
statiques de VC++ étaient incluses plusieurs fois, et le link
plantait.
On Fri, 27 Feb 2009 12:21:22 +0100, Sylvain Togni <"sylvain.togni at visionobjects.com">:
La version C++ par contre c'est un fichier MSVCPxx.dll qu'il faut déployer sur la machine cible.
C'est plus compliqué que ça.
Pour qu'un exécutable compilé avec VC++ 2008 fonctionne sous Windows 2000, il faut que msvcm90.dll, msvcr90.dll et msvcp90.dll soient dans le même répertoire que l'exécutable. Pour que le même exécutable fonctionne sous Windows XP, il faut que ces trois fichiers, avec en plus un fichier Microsoft.VC90.CRT.manifest, soient dans un sous-répertoire appelé Microsoft.VC90.CRT.
Du coup, on se retrouve à recopier deux fois ces fichiers.
Mais le plus simple est d'indiquer au linker d'utiliser les bibliothèques statiquement (Properties/C/C++/Code Generation/Runtime Library/ Multi-threaded), ça fait un exécutable un peu plus gros (mais moins que l'exe + la DLL), et comme ça pas d'emmerdes.
Oui. J'ai toutefois vite eu des soucis quand j'ai voulu découper un projet en plusieurs morceaux (.lib je crois) : les bibliothèques statiques de VC++ étaient incluses plusieurs fois, et le link plantait.
Sylvain SF
Fabien LE LEZ a écrit :
C'est plus compliqué que ça.
non.
Pour qu'un exécutable compilé avec VC++ 2008 fonctionne sous Windows 2000, il faut que msvcm90.dll
non, c'est seulement pour du "managed or mixed code".
msvcr90.dll
non, ça c'est le runtime C.
et msvcp90.dll
non, ça c'est la STL.
soient dans le même répertoire que l'exécutable.
non, dans n'importe quel rep. du path. (pour une lib. utile, aucune ne l'est ici.)
Du coup, on se retrouve à recopier deux fois ces fichiers.
non.
Oui. J'ai toutefois vite eu des soucis quand j'ai voulu découper un projet en plusieurs morceaux (.lib je crois) : les bibliothèques statiques de VC++ étaient incluses plusieurs fois, et le link plantait.
le troll est finalement un art, la semaine a été éprouvante.
Sylvain.
Fabien LE LEZ a écrit :
C'est plus compliqué que ça.
non.
Pour qu'un exécutable compilé avec VC++ 2008 fonctionne sous
Windows 2000, il faut que msvcm90.dll
non, c'est seulement pour du "managed or mixed code".
msvcr90.dll
non, ça c'est le runtime C.
et msvcp90.dll
non, ça c'est la STL.
soient dans le même répertoire que l'exécutable.
non, dans n'importe quel rep. du path.
(pour une lib. utile, aucune ne l'est ici.)
Du coup, on se retrouve à recopier deux fois ces fichiers.
non.
Oui. J'ai toutefois vite eu des soucis quand j'ai voulu découper un
projet en plusieurs morceaux (.lib je crois) : les bibliothèques
statiques de VC++ étaient incluses plusieurs fois, et le link
plantait.
le troll est finalement un art, la semaine a été éprouvante.
Pour qu'un exécutable compilé avec VC++ 2008 fonctionne sous Windows 2000, il faut que msvcm90.dll
non, c'est seulement pour du "managed or mixed code".
msvcr90.dll
non, ça c'est le runtime C.
et msvcp90.dll
non, ça c'est la STL.
soient dans le même répertoire que l'exécutable.
non, dans n'importe quel rep. du path. (pour une lib. utile, aucune ne l'est ici.)
Du coup, on se retrouve à recopier deux fois ces fichiers.
non.
Oui. J'ai toutefois vite eu des soucis quand j'ai voulu découper un projet en plusieurs morceaux (.lib je crois) : les bibliothèques statiques de VC++ étaient incluses plusieurs fois, et le link plantait.
le troll est finalement un art, la semaine a été éprouvante.
Sylvain.
psykzix
Fabien LE LEZ a écrit :
On Fri, 27 Feb 2009 12:21:22 +0100, Sylvain Togni <"sylvain.togni at visionobjects.com">:
La version C++ par contre c'est un fichier MSVCPxx.dll qu'il faut déployer sur la machine cible.
C'est plus compliqué que ça.
Pour qu'un exécutable compilé avec VC++ 2008 fonctionne sous Windows 2000, il faut que msvcm90.dll, msvcr90.dll et msvcp90.dll soient dans le même répertoire que l'exécutable. Pour que le même exécutable fonctionne sous Windows XP, il faut que ces trois fichiers, avec en plus un fichier Microsoft.VC90.CRT.manifest, soient dans un sous-répertoire appelé Microsoft.VC90.CRT.
Du coup, on se retrouve à recopier deux fois ces fichiers.
Mais le plus simple est d'indiquer au linker d'utiliser les bibliothèques statiquement (Properties/C/C++/Code Generation/Runtime Library/ Multi-threaded), ça fait un exécutable un peu plus gros (mais moins que l'exe + la DLL), et comme ça pas d'emmerdes.
Oui. J'ai toutefois vite eu des soucis quand j'ai voulu découper un projet en plusieurs morceaux (.lib je crois) : les bibliothèques statiques de VC++ étaient incluses plusieurs fois, et le link plantait.
Bonjour Je ne suis pas très expérimenté car je débute en C++. J'ai fait seulement quelques applications consoles sous windows avec visual c++. J'ai fait une petit bibliothèque statique lib utilisée par une autre application console et je n'ai eu aucun souci. J'ai fait des essais avec SDL qui nécessite aussi quelques lib et tout c'est bien passé. Mon seul problème était que je voulais que mes petites applications consoles s'exécute de manière autonome sur n'importe quel poste et en utilisant l'option /Multithread cela fonctionne. Je comprends mieux maintenant aussi ces histoires dll à associer à l'exécutable. Merci
Fabien LE LEZ a écrit :
On Fri, 27 Feb 2009 12:21:22 +0100, Sylvain Togni <"sylvain.togni at
visionobjects.com">:
La version C++ par contre c'est un fichier MSVCPxx.dll qu'il faut
déployer sur la machine cible.
C'est plus compliqué que ça.
Pour qu'un exécutable compilé avec VC++ 2008 fonctionne sous
Windows 2000, il faut que msvcm90.dll, msvcr90.dll et msvcp90.dll
soient dans le même répertoire que l'exécutable.
Pour que le même exécutable fonctionne sous Windows XP, il faut que
ces trois fichiers, avec en plus un fichier
Microsoft.VC90.CRT.manifest, soient dans un sous-répertoire appelé
Microsoft.VC90.CRT.
Du coup, on se retrouve à recopier deux fois ces fichiers.
Mais le plus simple est d'indiquer au linker d'utiliser les bibliothèques
statiquement (Properties/C/C++/Code Generation/Runtime Library/
Multi-threaded), ça fait un exécutable un peu plus gros (mais moins que
l'exe + la DLL), et comme ça pas d'emmerdes.
Oui. J'ai toutefois vite eu des soucis quand j'ai voulu découper un
projet en plusieurs morceaux (.lib je crois) : les bibliothèques
statiques de VC++ étaient incluses plusieurs fois, et le link
plantait.
Bonjour
Je ne suis pas très expérimenté car je débute en C++.
J'ai fait seulement quelques applications consoles sous windows avec
visual c++.
J'ai fait une petit bibliothèque statique lib utilisée par une autre
application console et je n'ai eu aucun souci.
J'ai fait des essais avec SDL qui nécessite aussi quelques lib et tout
c'est bien passé.
Mon seul problème était que je voulais que mes petites applications
consoles s'exécute de manière autonome sur n'importe quel poste et en
utilisant l'option /Multithread cela fonctionne.
Je comprends mieux maintenant aussi ces histoires dll à associer à
l'exécutable.
Merci
On Fri, 27 Feb 2009 12:21:22 +0100, Sylvain Togni <"sylvain.togni at visionobjects.com">:
La version C++ par contre c'est un fichier MSVCPxx.dll qu'il faut déployer sur la machine cible.
C'est plus compliqué que ça.
Pour qu'un exécutable compilé avec VC++ 2008 fonctionne sous Windows 2000, il faut que msvcm90.dll, msvcr90.dll et msvcp90.dll soient dans le même répertoire que l'exécutable. Pour que le même exécutable fonctionne sous Windows XP, il faut que ces trois fichiers, avec en plus un fichier Microsoft.VC90.CRT.manifest, soient dans un sous-répertoire appelé Microsoft.VC90.CRT.
Du coup, on se retrouve à recopier deux fois ces fichiers.
Mais le plus simple est d'indiquer au linker d'utiliser les bibliothèques statiquement (Properties/C/C++/Code Generation/Runtime Library/ Multi-threaded), ça fait un exécutable un peu plus gros (mais moins que l'exe + la DLL), et comme ça pas d'emmerdes.
Oui. J'ai toutefois vite eu des soucis quand j'ai voulu découper un projet en plusieurs morceaux (.lib je crois) : les bibliothèques statiques de VC++ étaient incluses plusieurs fois, et le link plantait.
Bonjour Je ne suis pas très expérimenté car je débute en C++. J'ai fait seulement quelques applications consoles sous windows avec visual c++. J'ai fait une petit bibliothèque statique lib utilisée par une autre application console et je n'ai eu aucun souci. J'ai fait des essais avec SDL qui nécessite aussi quelques lib et tout c'est bien passé. Mon seul problème était que je voulais que mes petites applications consoles s'exécute de manière autonome sur n'importe quel poste et en utilisant l'option /Multithread cela fonctionne. Je comprends mieux maintenant aussi ces histoires dll à associer à l'exécutable. Merci
