Je suis censé utiliser un programme d'analyse de données pour une expérience physique. Je ne peux pas l'obtenir pour compiler cependant.
Le code est vieux, pas vraiment compatible avec les versions actuelles du GCC à partir de ce que je peux trouver. Pour rendre les choses un peu plus difficiles, j'ai eu le code d'un gars qui avait modifié tous les maquillages pour le rendre compilé sur Mac. Je n'ai pas de C ++ - expérience, mais avec des pages homme, Google et Patience, j'ai réparé beaucoup d'erreurs sur le chemin, mais je suis coincé sur celui-ci, même après une semaine d'essais et de googling. P> < p> Je pense que le message d'erreur correspondant est le suivant: p> Quelle peut être la cause, et que peut être le remède? P> My g ++ - la version est Comme je l'ai dit, je n'ai aucune expérience avec C ++, alors peut-être que mes modifications de maquillage naïve ont détruit quelque chose. Mon manque d'expérience me fait aussi ne pas vraiment savoir quelles autres informations sont nécessaires pour m'aider, mais je serai heureux de répondre. P> p> libcommandlineinterface.so code> a été compilé par moi avant, sans aucun message d'erreur apparent: p>
g ++ (Ubuntu 4.4.3-4ubuntu5 ) 4.4.3 Code>, AMD64. P>
3 Réponses :
Les erreurs de liaison de la préoccupation commencent par: Les symboles multiples sont définis sont "standard" sur UNIX - et je n'ai jamais eu besoin de vous embêter avec eux sur Mac non plus, Bien que je ne fais pas de programmation graphique là-bas. p> Vous devez regarder Vous allez également avoir à vous inquiéter des vtables manquants: p> libcommandlineinterface.cc code> avec une attitude très préjudiciable et décider s'il fournit tout ce dont vous avez besoin. Vous pourriez être capable de l'enlever complètement. Si cela contient des trucs que vous avez besoin, vous devez cautériser le matériau qui définit
_start code> et
_end code> et
principal code> et ainsi de suite. < / p>
Merci beaucoup pour votre réponse. Le problème eh_frame_hdr code> a été résolu, il se trouve maintenant sur les messages à fourtilles manquants.
On dirait que vous avez oublié l'option Il est possible que les erreurs libtransfer.so soient liées au même drapeau étant omis. Une bibliothèque partagée est autorisée à avoir des références en suspens (qui sont résolues lorsque la bibliothèque est utilisée), mais une exécutable doit contenir tous les symboles résolus au moment de la liaison. C'est probablement une simplification excessive de la manière dont les choses sont, mais je n'ai jamais eu besoin d'entrer plus de détails sur la liaison dynamique de Linux. :) De toute façon, l'ajout de -shared code> ligne de commande lorsque vous générez le fichier
libccommandlineinterface.so code>. Cela expliquerait ces erreurs de définition multiples. Si la liaison pense que le fichier qu'il génère est un exécutable (au lieu d'une bibliothèque dynamique), il serait alors associé au code de démarrage, etc. Lorsque vous essayez d'utiliser ce fichier .so, ces symboles entrant dans le code de démarrage s'affrontera avec ceux qui sont ajoutés à l'exécutable qui utilise la bibliothèque dynamique. P>
-Shared code> peut également résoudre les erreurs de référence non définies. P>
Merci beaucoup, j'avais besoin d'ajouter -fic et à la commande compiler pour libcommandlineinterface.so code>. Maintenant, je suis un pas plus près de mon objectif :-)
Vous avez oublié de mentionner: il n'a pas réparer les références non définies, mais elle a rendu l'erreur EH_FRAME_HDR.
C'est résolu. Le problème EH_FRAME_HDR a été résolu par ce fil. Les références non définies ont été résolues en supprimant libtransfer.so code> après le premier
faire code>, puis directement exécuté
faire code>. Ne me demandez pas comment, mais cela a fait compiler. P>
"Le problème EH_FRAME_HDR a été résolu par ce fil ..." I> - Comment ou où? Je ne vois pas ça, ça a déclaré n'importe où.
@JWW: C'était il y a quelques années, mais dans un commentaire à la réponse acceptée, j'ai écrit que -shared code> (et apparemment
-fic code>) a fait le
eh_frame_hdr code> Les messages disparaissent.