Erreur "Aucun fichier source nommé" lors du débogage d'Eclipse CDT
J'ai un projet avec une bibliothèque partagée (chargée dynamiquement) et je tente de le déboguer. Je reçois le message d'erreur suivant:
No source file named /home/username/Code/path/to/project/MyFile.cpp.
Après avoir recherché d'autres threads, je me suis assuré que je compilais avec -g et que les dossiers appropriés se trouvent dans l'onglet des chemins source des configurations de débogage. Ce qui est étrange, c’est qu’il donne le bon chemin absolu: le fichier qu’il référence existe, je ne comprends donc pas pourquoi il ne pense pas qu’il soit là.
Quelqu'un sait quoi faire à ce sujet?
Je viens de rencontrer le même problème, même si mes points d'arrêt se trouvaient dans l'exécutable lui-même et non dans une bibliothèque partagée. Pour résoudre ce problème, je devais ouvrir la "Configuration de débogage", sélectionner ma configuration de débogage et ajuster les paramètres suivants:
- En bas, un lien "Sélectionnez autre ..." permet de sélectionner le lanceur de création de processus. Cliquer sur le lien. Cochez la case "Utiliser les paramètres spécifiques à la configuration". Sélectionnez "Lanceur de processus de création standard" et appuyez sur "OK".
- Allez dans l'onglet "Débogueur" et sélectionnez "Débogueur: gdb/mi" dans le haut de l'onglet. Ce qui peut/peut ne pas faire la différence: Sur le même onglet, il y a aussi une case à cocher "Utiliser le chemin complet du fichier pour définir les points d'arrêt" - j'ai joué avec cela, mais cela ne semble pas affecter le problème observé (évidemment, nos chemins sources sont déjà des chemins complets).
Pour les points d'arrêt dans les bibliothèques partagées, vous aurez peut-être besoin d'informations supplémentaires (en particulier sur les points d'arrêt différés) de Débogage avec Eclipse cdt et gdb et Pourquoi Eclipse cdt ignore-t-il les points d'arrêt .
Remarque: Ceci fait référence à Eclipse Kepler (4.3) et à gdb 7.4.
J'ai eu le même problème, mais dans mon cas c'était de ma faute. Certains de mes projets étaient configurés pour la configuration de publication et le débogueur ne pouvait naturellement pas trouver les informations du fichier source.
J'ai eu le même problème. Je ne pouvais pas définir de point d'arrêt dans un fichier de bibliothèque partagée (.so), compilé à un emplacement différent de celui de mon programme. Pour résoudre ce problème:
- Aller à la configuration de débogage, onglet Source
- Ajoutez un répertoire de compilation (j'ai utilisé l'emplacement du makefile principal qui compile tous les processus, pas celui où se trouve le makefile de ce processus).
- cliquez également sur "Les sous-répertoires sont également utilisés pour la compilation" (mon makefile de sous-processus est compilé dans un sous-répertoire de l'emplacement principal)
Je n'ai pas trouvé comment faire cette modification pour toutes les configurations de débogage futures et antérieures afin de ne pas avoir à ajouter ce répertoire à chaque fois, mais j'essaierai de mettre à jour plus tard si je le découvre.
Cela peut arriver si vous avez à la fois cygwin et mingw (ou une autre variante). Si gcc de cygwin est utilisé pour compiler la source, vous aurez un chemin cygwin dans l'exécutable. Ensuite, si le débogueur provient de mingw, gdb ne pourra pas interpréter le chemin cygwin. Le moyen le plus simple de résoudre ce problème est d’exécuter -> Configurations de débogage -> Débogueur et de définir le chemin complet de cygwin gdb (C:\cygwin64\bin\gdb.exe). Cela a résolu le problème pour moi.
J'ai suivi le commentaire de @Andreas Fester sous l'onglet Débogueur dans les paramètres de Configuration de débogage, mais je ne trouve pas le "Débogueur: gdb/mi", mais dans l'onglet Source, j'ai supprimé tous les éléments et ajouté "Chemin de fichier absolu" en cliquant sur le bouton "Ajouter .. "bouton situé à droite de la fenêtre. Cela m'a aidé sur ce problème
J'ai eu le même problème mais ma solution était différente. Ouvrez les répertoires du projet "debug/src" + "release/src" et assurez-vous qu'aucun fichier [nomfichier] .d ne contient le nom d'un fichier source susceptible d'avoir changé ou n'existe plus. J'en ai eu un, je l'ai supprimé et depuis plus aucune erreur.
Je suppose donc, du moins dans mon cas, que les erreurs sont créées par des objets tombés en dehors de la portée.