none
Problèmes de compilation erreur C1083 RRS feed

  • Question

  • Bonjour à tous.

    Je suis totalement débutant dans l'utilisation de visual studio et j'ai quelques connaissances en C++ mais rien de bien folichon.

    Dans le cadre de mon travail, je dois recompiler une dll 32 bits pour qu'elle tourne en 64 bits. J'ai configuré mon microsoft visual studio 2012 pour qu'il utilise le compilateur 64 bits. Le seul souci c'est que cette dll date de 2001 et que plus personne n'y a touché depuis dans ma boite, et tous les experts en C++ sont partis depuis, je suis le seul avec un minimum de connaissance dans ce domaine.

    Le problème survient à la compilation :

    fatal error C1083: Impossible d'ouvrir le fichier source : 'I:\Product\Data\adr.cpp' : No such file or directory

    Et j'en ai des dizaines comme ça.

    Le chemin d'accès I:\Product n'existe effectivement pas (en réalité j'ai même pas de serveurs I:\ mappé), mais comment faire pour lui donner un autre chemin d'accès au fichier ? A part supprimer chaque fichier qu'il ne trouve pas et les lui redonner avec le bon chemin d'accès ? Parce qu'il y a une bonne centaine de fichier, entre les .cpp et les .h, donc si je dois tous me les faire à la main, je vais en avoir pour longtemps.

    Je vous remercie d'avance de votre aide.

    Cordialement,

    Archillion.

    vendredi 24 août 2012 07:25

Réponses

  • Alors deux cas de figures :

    Ou ceux qui vous ont précédé on travaillé comme des sagouin, soit ils ont travaillé à l'ancienne (mais c'est pas super propre).

    Le résultat est le même, des chemins en dur, mais la motivation n'est pas la même.

    Si c'est à l'ancienne, cette dépendance avec le lecteur I: n'est pas accidentel mais répond à des contraintes de développement.

    Si vous changez tous les chemins, à un moment vous allez tombé sur ces même contraintes et être obligé de faire la même chose qu'eux, mapper un disque I: sur la racine du projet. Cela peut être des limitations sur certain outils utilisés dans la chaine de compilation ou la gestion des environnements de votre entreprise.

    Si les anciens étaient des cadors, c'est plus cette hypothèse la plus probable, et donc ne ramez pas contre le courant, mappez correctement votre lecteur I:. (avec subst ou autre outils).

    S'ils ont travaillé comme des sagouins, le mapping de I: ne sera que la première étape d'un long chemin de croix. Et pour éviter que d'autres subissent les mêmes affres, il serait judicieux de corriger une à une ces bêtises.

    Dans ce cas, le ou les chemins en durs sont dans les fichiers projets de VS, qui sont de simples fichiers XML. La correction sera donc un simple rechercher-remplacer des chemins trouvés dans ces fichiers.

    Pensez à utiliser des chemins relatifs et les pseudo-variable d'environnement mis à disposition par VS, pour votre correction des chemins, n'est-ce pas ? ;-)

    P.S.: Normalement, les cadors documentent ce genre de détails, mais les personnes qui restent (DSI et autres boulets) ont tendances à "égarer" ces documents, qu'un stagiaire avisé devrait très instamment demander à ces mêmes boulets.


    Paul Bacelar, Ex - MVP VC++

    • Marqué comme réponse Archillion jeudi 30 août 2012 15:33
    vendredi 24 août 2012 15:14
    Modérateur

Toutes les réponses

  • En attendant une réponse, je me suis amusé à supprimer chaque fichier et à tous les remettre. Je n'ai plus aucune erreur de ce genre là

    fatal error C1083: Impossible d'ouvrir le fichier source : 'I:\Product\Data\adr.cpp' : No such file or directory

    Par contre maintenant j'ai que dès comme ça :

    fatal error C1083: Impossible d'ouvrir le fichier include adr.h : No such file or directory

    Pourtant ils sont dans le même dossier que mes .cpp et l'include est bien en place : #include <adr.h> donc je ne comprends pas trop. Y a-t-il une configuration particulière à mettre en place pour qu'il les trouve ?

    • Marqué comme réponse Archillion jeudi 30 août 2012 15:33
    • Non marqué comme réponse Archillion jeudi 30 août 2012 15:33
    vendredi 24 août 2012 12:50
  • Alors deux cas de figures :

    Ou ceux qui vous ont précédé on travaillé comme des sagouin, soit ils ont travaillé à l'ancienne (mais c'est pas super propre).

    Le résultat est le même, des chemins en dur, mais la motivation n'est pas la même.

    Si c'est à l'ancienne, cette dépendance avec le lecteur I: n'est pas accidentel mais répond à des contraintes de développement.

    Si vous changez tous les chemins, à un moment vous allez tombé sur ces même contraintes et être obligé de faire la même chose qu'eux, mapper un disque I: sur la racine du projet. Cela peut être des limitations sur certain outils utilisés dans la chaine de compilation ou la gestion des environnements de votre entreprise.

    Si les anciens étaient des cadors, c'est plus cette hypothèse la plus probable, et donc ne ramez pas contre le courant, mappez correctement votre lecteur I:. (avec subst ou autre outils).

    S'ils ont travaillé comme des sagouins, le mapping de I: ne sera que la première étape d'un long chemin de croix. Et pour éviter que d'autres subissent les mêmes affres, il serait judicieux de corriger une à une ces bêtises.

    Dans ce cas, le ou les chemins en durs sont dans les fichiers projets de VS, qui sont de simples fichiers XML. La correction sera donc un simple rechercher-remplacer des chemins trouvés dans ces fichiers.

    Pensez à utiliser des chemins relatifs et les pseudo-variable d'environnement mis à disposition par VS, pour votre correction des chemins, n'est-ce pas ? ;-)

    P.S.: Normalement, les cadors documentent ce genre de détails, mais les personnes qui restent (DSI et autres boulets) ont tendances à "égarer" ces documents, qu'un stagiaire avisé devrait très instamment demander à ces mêmes boulets.


    Paul Bacelar, Ex - MVP VC++

    • Marqué comme réponse Archillion jeudi 30 août 2012 15:33
    vendredi 24 août 2012 15:14
    Modérateur
  • Bonjour.

    Tout d'abord merci de votre réponse. Je ne sais pas comment les développeurs ont travaillés, étant donné que le peu de documentations qu'il reste à ce sujet concernent plus le développement en lui même et l'utilisation du programme (qui est une DLL appelée par un ERP en PL/SQL), mais rien sur la configuration de visual studio.

    De mon côté, je m'occupe de corriger cette défaillance afin que si j'ai un jour un successeur, il ne soit pas dans le même cas que moi.

    J'ai suivi vos conseils, et j'ai donc remappé I:\ sur la racine du projet, n'ayant pas trouvé un seul fichier .xml avec la recherche windows.

    Effectivement, je n'ai plus eu d'erreurs "fatal error C1083: Impossible d'ouvrir le fichier source : 'I:\Product\Data\adr.cpp' : No such file or directory", et ce sans aucun bidouillage quelconque. Par contre, j'ai encore une fois les erreurs "fatal error C1083: Impossible d'ouvrir le fichier include adr.h : No such file or directory"

    Encore une fois, je suis perdu. Demain j'ai un coup de main d'un des deux développeurs qui a bossé sur ce projet. Mais vu que c'est moyennant finance bien entendu, j'aimerais pouvoir régler le problème sans son aide. Je vais continuer à chercher une solution à mon problème en attendant un avis :)

    Encore une fois, merci pour votre aide, ça m'a déjà enlevé une grosse épine du pied.

    lundi 27 août 2012 07:34
  • Ne pas régler cela par une simple configuration donnée par téléphone ou ne pas faire référence à une documentation (peut-être égaré par le client), et directement mettre le doigts sur le portefeuille, c'est pas très pro.

    Par fichier XML, je parlais du format, pas de l'extension du fichier. ;-)

    C'est les fichiers projets qui sont au format xml, donc facilement éditable avec un simple notepad.

    S'il n'y a pas de vraies justifications techniques à la présence des chemins en dur dans les fichiers projets, c'est que c'est des guignolots qui connaissent comment se rendre indispensables pour faire cracher au bassinet.


    Paul Bacelar, Ex - MVP VC++

    lundi 27 août 2012 10:06
    Modérateur
  • En fait, les fichiers étaient bien donnés en dur dans le projet. Je l'ai vu en ouvrant le fichier .sln avec notepad. Donc j'ai recréé l'arborescence I:\ et j'ai indiqué le chemin d'accès corrects pour les include qui plantaient encore. Après 2-3 modifications, je n'ai plus eu de problèmes. L'éditeur de liens par contre a posé problème, mais le développeur qui est passé m'a réglé ce problème. Donc sujet résolu, à part un dernier petit truc.

    J'ai posé une question sinon sur le forum developpez.net dans la partie correspondante, mais sans succès. Peut-être en saurez-vous plus ici.

    Je cherche une alternative à ociw32.lib (librairie permettant de se connecter à une base de données Oracle) mais pour du 64 bits, de préférence en restant toujours dans la solution OCI.

    Parce que ma DLL compile en 32 bits, mais en 64 ... c'est pas trop ça !

    jeudi 30 août 2012 06:45
  • Vous devriez créer un autre sujet de discution.

    Vous parlez de ceci :

    http://www.developpez.net/forums/d1256554/bases-donnees/oracle/interfaces-programmation/ociw32-lib-64-bits/

    ?

    Je ne vois qu'un simple problème de link standard. Etes-vous sûr d'avoir correctement renseigner toutes les librairies utilisés par votre exécutable dans votre projet 64bits ?


    Paul Bacelar, Ex - MVP VC++

    jeudi 30 août 2012 09:43
    Modérateur
  • Il n'y a aucune différence entre les deux projets, ils sont totalement identiques, j'ai juste indiqué un autre compilateur.

    C'est bien ce sujet là :)

    Je note celui ci comme résolu ;)

    Merci à vous :)

    jeudi 30 août 2012 15:33