Je viens de mettre mes source a jour dans ce poste :
http://www.developpez.net/forums/sho...2&postcount=14
histoire de ne pas reposter 50 lignes ici ;°)
Une idée ? Parce-que moi je commence à être paumé là ..!
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Je viens de mettre mes source a jour dans ce poste :
http://www.developpez.net/forums/sho...2&postcount=14
histoire de ne pas reposter 50 lignes ici ;°)
Une idée ? Parce-que moi je commence à être paumé là ..!
d'après le diagnostic de ton compilo (voir mon post ci-dessus), il faut t'assurer :
1) que "panel-applet.h" contient bien les routines que tu appelles
2) que dans ton makefile, il y a bien dans les flags de compile le chemin pour trouver ce .h : -Irépertoire
merci, alors :
1 : Oui, ça fonctionnait très bien avant que je sépare les fichiers.
2 : Dans mon flag de compilation j' ai bien -I/usr/include/panel-2.0
Chez moi, ça compile lorsque tu remplaces:
par
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
respectivement, dans CFLAGS et LDFLAGS.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
P.S Je suis sous Ubuntu, et j'ai dû installer au préalable les fichiers de développement pour la bibliothèque panel-applet i.e. paquet libpanel-applet2-dev
Thierry
"The most important thing in the kitchen is the waste paper basket and it needs to be centrally located.", Donald Knuth
"If the only tool you have is a hammer, every problem looks like a nail.", probably Abraham Maslow
FAQ-Python FAQ-C FAQ-C++
+
Ca marche !
Ce qui m' étonne grandement c' est que j' ai pu le compiler plusieurs fois auparavant (faire des test avec le panel et tout et tout..).
Bon maintenant ça marche CA MARCHE !!
Je vais travailler mon maigre savoir des makefiles pour le futur, et avancer dans mon programme .
Encore merci à tous, voilà, ouf ! ;°D
On parle bien des prototypes et non des routines elles même, on est bien d'accord ?Envoyé par souviron34
Sauf macro, en quoi un manquement de prototype pourrait-il créer une erreur de l'éditeur de lien ?
Il y aurait des erreurs de compilation "fichier ...h introuvable...". Et une fois de plus, ça n'empêche pas le lien avec les fonctions.2) que dans ton makefile, il y a bien dans les flags de compile le chemin pour trouver ce .h : -Irépertoire
Bien comprendre les messages d'erreurs permet de mieux le corriger. Ici, c'est un problème de fonction inconnue au moment de l'édition de lien.
- Soit la fonction est static
- Soit elle est absente du projet
- erreur d'identificateur
- fonction non implémentée
- unité de compilation manquante
- bibliothèque manquante
tu t'es répondu à toi-même
Ce que je voulais dire, c'est que :
1) si le .h existait mais ne contenait pas la définition des routines qu'il appelait, et que lui les utilisait => erreur (comme tu le dis "absente du projet erreur d'identificateur ou fonction non implémentée")
2) vu le diagnostic qu'il avait, ça aurait pu être "erreur "unité de compilation manquante ou bibliothèque manquante")
Et j'avais traité le 1)...
Si tu dois faire du développement 'a-la-main', c'est à dire sans IDE, ce qui est souvent le cas sous Linux[1], il faut absolument que tu prennes le temps de maitriser make. C'est pas difficile, mais il faut, comme toujours en informatique, être très rigoureux.
Petite initiation : http://emmanuel-delahaye.developpez.com/make.htm
Plus complet : http://gl.developpez.com/tutoriel/outil/makefile/
----------------------
[1] bien que Code::Blocks existe sous Linux si tu as un environnement graphique basé sur Gnome, KDE...
Je ne vois aucune relation de cause à effet entre programmer sous Linux, et devoir programmer "à la main". Parmi les EDIs les plus populaires: Code::Blocks, Anjuta, Kdevelop, Eclipse, etc. D'ailleurs, la plupart de ces EDI génèrent des Makefiles.
C'est en revanche indéniable que maîtriser make ainsi que les GNU Autotools est un grand avantage si on désire participer à certains projets de développement communautaire, ou à toute pratique professionnielle sous Unixoïde.
Un outil que j'apprécie de plus en plus dans le domaine de l'automatisation du processus de compilation, c'est SCons http://www.scons.org/. Certains projets ont complètement abandonné make au profit d'alternatives de plus haut niveau comme Scons (python) ou Rake (Ruby). Apprendre à utiliser make et les autotools reste toutefois une très bonne chose, et sera probablement encore longtemps indispensable à tout programmeur sous Unixoïde. Toutefois, scons, par exemple, simplifie beaucoup notamment le portage d'applications sur différentes plateforme, opération qui devient très vite cass-tête avec make. C'est bien de savoir que des alternatives existent, et qu'elles simplifient parfois la vie.
Thierry
"The most important thing in the kitchen is the waste paper basket and it needs to be centrally located.", Donald Knuth
"If the only tool you have is a hammer, every problem looks like a nail.", probably Abraham Maslow
FAQ-Python FAQ-C FAQ-C++
Je suis d'accord dans le principe, mais la culture Unixienne (que je n'ai pas) s'accroche à [g]cc + emacs/vi + make. Certains as du clavier considérant que emacs ou vi sont des IDE jamais égalés. (c'est possible, je disais pareil de Borland C 3.1).
Oui, Kdevelopp utilise aussi Autoconf et Automake, avec génération de floppées de fichiers intermédiaires envahissants, sans compter les erreur de synchronisations fréquentes et les besoins fréquents de tout régénérer...Parmi les EDIs les plus populaires: Code::Blocks, Anjuta, Kdevelop, Eclipse, etc. D'ailleurs, la plupart de ces EDI génèrent des Makefiles.
Jamais pu développer de projet avec ça...
Eclipse, + CDT, c'est ... bizarre...
Code::Blocks déjà cité est correct mais pas très stable (à l'époque, il y a un an) et lent, très lent sur ma vieille machine Linux...
Anjuta, jamais essayé...
- Je confirme la lenteur de Code::Blocks sur ma machine aussi (PIII, 660 MHz, Ubuntu 6.06/Windows XP)
- Eclipse + CDT: pourquoi bizarre? Par contre, c'est lent...
- Kdevelop: je n'ai jamais essayé
- Anjuta: la nouvelle version est prometteuse...
- gcc + emacs/vim + make/scons/autres: j'ai vu de telles solutions parfois mieux intégrés (à coup de plugins) que certains EDI du marché. C'est toutefois difficile quand on débute (je parle de mon cas) à atteindre ce degré d'intégration. J'utilise actuellement vim + scons pour coder un petit EDI léger qui répondrait à mes besoins (enfin bon, c'est un projet qui avance lentement).
Thierry
"The most important thing in the kitchen is the waste paper basket and it needs to be centrally located.", Donald Knuth
"If the only tool you have is a hammer, every problem looks like a nail.", probably Abraham Maslow
FAQ-Python FAQ-C FAQ-C++
moi c'est xemacs et make... et X/Motif
Mille excuses, lorsque je parle de emacs/vim, xemacs est implicitement compris dans le lot.moi c'est xemacs et make... et X/Motif
Thierry
"The most important thing in the kitchen is the waste paper basket and it needs to be centrally located.", Donald Knuth
"If the only tool you have is a hammer, every problem looks like a nail.", probably Abraham Maslow
FAQ-Python FAQ-C FAQ-C++
Répondre avec citation
Partager