Bonjour.



Voici mon problème : Il y a deux jours j'ai voulu installer visual c++ express edition, tout se passe bien, mais lorsque j'ai voulu tester mon programme sur un autre PC, ça ne m'arche pas.



Sur ces mots, je suis allé voir de nombreux forum, et tout le monde a ce problème. Beaucoup arrivent à s'en sortir, mais moi j'ai un peu de mal je l'avoue.

J'ai compris que ça venait des bibliothèques runtime, et que ca dépendait du fait que ces dernières étaient statiques ou dynamiques (cela se change dans les options du compilateur : MultiThread ou DLL MultiThread )
Comme il était indiqué, pour que ça marche ailleurs, j'ai mis Multithread (/MD), mais en faisant cela, ca ne compile plus (avec dll multithread ça marche, mais que sur mon PC) et voila ce qui s'affiche :



Si vous avez déja résolu ce problème, par pitié aidez moi je vais craquer !!!

EDIT : une solution consiste a installer des dll sur le PC qui a besoin de lancer le programme. Moi je voudrais simplement faire comme sur code::block, c'est à dire compiler... Et puis voilà !

D'avance, merci !

Salut,

Si tu compile en utilisant la bibliothèque dynamique (option "Multithread DLL"), tu n'as pas le choix, il faut que la DLL correspondant à la bibliothèque C de Visual Studio soit installée sur le(s) PC(s) cible(s). C'est parfaitement normal et logique.

Si malgré tout tu ne veux pas de cette "complication", il faut donc effectivement compiler contre la bibliothèque statique (option "Multithread"). Cela fonctionne parfaitement... jusqu'au moment où tu utilises en plus une autre bibliothèque qui a été compilée contre la bibliothèque dynamique (ce qui semble être le cas ici). L'éditeur de liens se trouve maintenant face à un problème : les mêmes symboles (fonctions, variables globales) sont disponibles dans deux bibliothèques différentes.

Tu peux essayer d'utiliser l'option /FORCE pour contraindre l'éditeur de liens à passer outre les multiples définitions, mais le comportement du programme semble dans ce cas indéfini (MSDN dixit : "A file created with this option may not run as expected").

Autre solution possible (à tester) : l'option /NODEFAULTLIB:msvcrt.lib, pour exclure la bibliothèque dynamique (msvcrt.lib) et contraindre l'éditeur de liens à utiliser la version statique (libcmt.lib).

Avec /NODEFAULTLIB:...

------ Début de la génération : Projet : testsdl, Configuration : Release Win32 ------
Édition des liens en cours...
SDLmain.lib(SDL_win32_main.obj) : error LNK2001: symbole externe non résolu __imp__strrchr
SDLmain.lib(SDL_win32_main.obj) : error LNK2001: symbole externe non résolu __imp__fprintf
SDLmain.lib(SDL_win32_main.obj) : error LNK2001: symbole externe non résolu __imp___iob
SDLmain.lib(SDL_win32_main.obj) : error LNK2001: symbole externe non résolu __imp__remove
SDLmain.lib(SDL_win32_main.obj) : error LNK2001: symbole externe non résolu __imp__fopen
SDLmain.lib(SDL_win32_main.obj) : error LNK2001: symbole externe non résolu __imp__fgetc
SDLmain.lib(SDL_win32_main.obj) : error LNK2001: symbole externe non résolu __imp__fclose
SDLmain.lib(SDL_win32_main.obj) : error LNK2001: symbole externe non résolu __imp__setbuf
SDLmain.lib(SDL_win32_main.obj) : error LNK2001: symbole externe non résolu __imp__setvbuf
SDLmain.lib(SDL_win32_main.obj) : error LNK2001: symbole externe non résolu __imp__freopen
C:\Documents and Settings\BARBA-ROSSA\Bureau\testsdl\testsdl\Release\testsdl.exe : fatal error LNK1120: 10 externes non résolus
Le journal de génération a été enregistré à l'emplacement "file://c:\Documents and Settings\BARBA-ROSSA\Bureau\testsdl\testsdl\Release\BuildLog.htm"
testsdl - 11 erreur(s), 0 avertissement(s)
========== Génération : 0 a réussi, 1 a échoué, 0 mis à jour, 0 a été ignoré ==========

Avec /FORCE:
Cette application n'a pas pu démarrer car MSVCR80.dll est introuvable. La réinstallation de cette application peut corriger le problème.

Avec les deux:
Plein d'erreurs : 20 erreurs et 6 warnings

Je désespere

Ouais, pour /NODEFAULTLIB, je m'y attendais un peu : ta bibliothèque tierce (SDLmain.lib) a été compilée pour utiliser la version dynamique de la bibliothèque C de Visual Studio, si tu veux lui faire utiliser la version statique, elle aime pas... Plus sérieusement, dans la version dynamique de la bibliothèque C de Visual Studio, les fonctions portent des noms légèrement différents que dans la version statique (@Microsoft: j'aimerais bien savoir pourquoi ? ), donc l'éditeur de liens ne peut pas trouver les fonctions requises par SDLmain.

Quant à /FORCE, je ne savais pas ce que ça donnerait mais bon l'explication de la MSDN ne laissait guère d'espoir...

À mon avis, deux solutions : soit tu trouves une version de SDLmain qui a été compilée contre la bibliothèque C statique (éventuellement, si tu peux avoir les sources de SDLmain, tu la re-compiles toi-même), soit... tu utilises cette bibliothèque comme elle a été conçue pour être utilisée, et tu linkes ton propre programme contre la bibliothèque C dynamique (ce qui impliquera de s'assurer que msvcrt80.dll est installée sur le PC cible).

Ben en fait je crois que je vais rester au bon vieux code::block

Pourquoi c'est si compliqué ?!

Merci infiniment pour ces réponses, bien qu'elles ne résolvent pas mon problème.

À ta place, je ne m'arrêterai pas pour si peu. L'obligation d'installer la bibliothèque msvcrt80.dll n'est pas si contraignante que ça. De toute façon, tes utilisateurs devront installer cette bibliothèque sitôt qu'il voudront utiliser un programme développé avec Visual C++ 2005 (enfin, ceux qui utilisent la Visual C Runtime Library dynamique, c'est-à-dire la plupart). Si ce n'est pas _ton_ programme qui les oblige à l'installer, ce sera un autre...

(La plupart des développeurs s'arrangeront de toute manière pour que msvcrt80.dll soit automatiquement installée si nécessaire, lorsqu'ils développeront le programme d'installation de leur logiciel.)

(Il est vrai que Visual Studio 2005, même dans ses versions Express, a un petit côté "Usine à gaz" et qu'en saisir toutes les subtilités n'est pas évident, a fortiori pour un débutant --- même si d'après moi ça vaut le coup d'y consacrer un peu de temps. Cela dit, si tu es plus à l'aise avec Code::Blocks, continue à l'utiliser. )

Hum... tu as raison, cela dit, comment fait code::block pour que l'utilisateur n'ai pas besoin d'installer ces librairies ?

C'est simplement parce que Code::Blocks n'utilise pas la bibliothèque C de Visual Studio, mais celle du projet GNU. À cela s'ajoute le fait qu'apparemment la version de SDLmain.lib conçue pour être utilisée avec GCC (le compilateur derrière Code::Blocks) utilise la bibliothèque C GNU de manière statique (alors que la version conçue pour être utilisée avec le compilateur Visual utilise sa bibliothèque de manière dynamique), ce qui fait que tout le code nécessaire au bon déroulement du programme se trouve réuni dans le fichier exécutable.

Ok merci bien pour ces réponses aussi rapides !

Bonjour a tous,

je reprend ce meme sujet car j'ai exactement le même problème mais je n'est pas la même solution car ca marche pas.
J'ai fait un programme sous visual c++ sous vista en sdl.
Quand je veut utiliser mon programme sous XP, il me met le même message d'erreur

Citation : Window

Cette application n'a pas pu démarer car la configuration est incorrecte. Réinstaller pourrais résoudre le problème

Selon ce que j'ai pu lire sur différent forum, le problème viendrais d'un dll nommé "msvcrt80.dll"
Une solution évoquer dans les précédent message serai de l'installer chez le client.
Ma question est :


je vous remercie pour vos reponse

C'est juste qu'il ne faut pas mélanger les patates et les carottes. L'ensemble de tes librairies doivent être compiler pour utiliser la même CRT, sinon tu t'exposes à des problèmes infame.

Au pire si la SDL n'est pas fourni comme il se doit en version ST,MT, dll ou statique tu la recompiles.

mon probleme c'est que j'ai deja fait des programme qui marche sur XP en les metant en "DLL multithread (/MD)" et en enlevant "msvcrt.lib"
et ca marcher tres bien

mais la pour ce nouveau programme il me rajoute une erreur :

Citation : Visual c++

SDLmain.lib(SDL_win32_main.obj) : error LNK2019: symbole externe non résolu __imp__fprintf référencé dans la fonction _ShowError

je ne sait pas quoi faire

de plus je ne sais pas reconpiler les dll