Discussion :

[Jipété]

Bonsoir,

je vais péter un plomb ! C'est à peine plus sophistiqué qu'un helloworld, le machin fait 43 lignes...

Il commence comme ça

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
#include <stdio.h>
#include <ftdi.h>

dans le main on trouve des choses genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
    int ret;
    struct ftdi_context ftdic;
    if ((ret = ftdi_usb_open(&ftdic, 0x0403, 0x6001)) < 0)

dans le .h on trouve son pendant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

    int ftdi_usb_open(struct ftdi_context *ftdi, int vendor, int product);

j'ai vérifié (vous allez voir pourquoi juste après) que j'avais bien les 2 .h au bon endroit (je suis sous Linux, donc "locate" me donne l'emplacement d'un fichier) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
# locate stdio.h
/usr/include/stdio.h
 
# locate ftdi.h
/usr/include/ftdi.h

et le .c vient d'un paquet téléchargé depuis les dépots officiels de Debian, donc aucune bidouille de ma part.

Malheureusement, avec tout ça de positif, quand j'ouvre le .c dans Geany et que j'appuie sur F8, si la compilation est réussie (génération d'un .o), quand j'appuie sur F9 la création échoue avec des trucs genre simple.c:(.text+0x60): undefined reference to `ftdi_usb_open'
J'avais testé avant avec gcc -Wall simple.c -o simple, qui me sortait le même résultat lamentable

Si quelqu'un a une idée, je la lirai avec grand plaisir parce que là, c'est la première fois que je vois un truc pareil...

[foetus]

Oui très simple

Soit:

• il te manque un "-lftdi" lorsque tu "linkes" (lies) (*)
• il faut faire une librairie statique: tu crées un nouveau projet pour avoir une bibliothèque .a (ou .so, je confonds sous Linux ) et l'utiliser lors du "linkage" (liaison)
• il faut faire une librairie statique en mode bourrin, en compilant en plus du source simple.c, toutes les sources de cette bibliothèque

* -> Édit: je me suis gouré c'est l minuscule pour la bibliothèque

[Jipété]

Mais tu es partout

Oui très simple

Pour tout le monde, jamais pour moi

• il te manque un "-Lftdi" lorsque tu "linkes" (lies)

Même erreur...

• il faut faire une librairie statique: tu crées un nouveau projet pour avoir une bibliothèque .a (ou .so, je confonds sous Linux ) et l'utiliser lors du "linkage" (liaison)

Comme ça ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
gcc -Wall -static -o ftdi.a /usr/include/ftdi.h
gcc -Wall -Lftdi.a -o simple simple.c

Même erreur

• il faut faire une librairie statique en mode bourrin, en compilant en plus du source simple.c, toutes les sources de cette bibliothèque

Je ne vois pas la différence avec le point précédent...

[foetus]

Tu ne comprends pas ce que tu fais ou

Parce que le source se trouve dans le fichier ftdi.c

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int ftdi_usb_open(struct ftdi_context *ftdi, int vendor, int product)
{
    return ftdi_usb_open_desc(ftdi, vendor, product, NULL, NULL);
}

gcc -Wall -Lftdi.a -o simple simple.c.
Je ne sais pas parce qu'il ne faut pas mettre l'extension. Avec l'extension je ne sais pas ce que fait gcc
Mais en théorie lorsque tu fais un un "-lXXX", gcc va chercher dans "ces chemins" un fichier "libXXX.a"

Est-ce que tu as installé cette bibliothèque avec "./configure; make; make install" ?
À l'époque cela me gonflait grave que chaque installation finissait dans le dossier "/usr/" (/usr/lib, /usr/include, ...), qui n'était pas dans "les chemins" de gcc
Donc plus un gcc -Wall -lftdi -L/usr/lib/ -o simple simple.c.


Édit: je me suis gouré c'est l minuscule pour la bibliothèque


Sinon c'est:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
gcc -c main.c
gcc -c ftdi.c
gcc -c ftdi_stream.c
gcc -o simple main.o ftdi.o ftdi_stream.o

Je ne vois pas la différence avec le point précédent...

Normal, c'est 3 fois la même chose, mais pas la même façon de faire

[picodev]

Bonjour,

quand on utilise une bibliothèque externe (ce qui semble être ton cas) il faut savoir plusieurs choses :

• il faut donner au préprocesseur le chemin où il va trouver les headers, cela se fait via l'option -I suivi du chemin pour gcc
• il faut donner à l'éditeur des liens le chemin où trouver les bibliothèques et les bibliothèques, cela se fait via les options -L suivi du chemin et -l (une bibliothèque nommée libftdi.so donne l'option -lftdi) si les bibliothèques sont dynamiques.

Il faut ensuite se référer à la documentation de ton compilateur pour savoir quelles options utiliser, voire de ton IDE pour savoir comment les lui transmettre. Il faut aussi se référer à la doc de la bibliothèque pour vérifier qu'elle n'offre pas un moyen simple pour récupérer les chemins (par exemple via pkg-config sous linux).

Je ne peux que te recommander d'utiliser un gestionnaire de projet (make ou autre …) qui te simplifiera grandement la vie.

[Jipété]

Il faut ensuite se référer à la documentation de ton compilateur pour savoir quelles options utiliser, voire de ton IDE pour savoir comment les lui transmettre. Il faut aussi se référer à la doc de la bibliothèque pour vérifier qu'elle n'offre pas un moyen simple pour récupérer les chemins (par exemple via pkg-config sous linux).

Je ne peux que te recommander d'utiliser un gestionnaire de projet (make ou autre …) qui te simplifiera grandement la vie.

Beaucoup de travail et de trafic et d'études pour trois misérables .c, le jeu n'en vaut pas la chandelle mais merci quand même d'avoir participé.

Tu ne comprends pas ce que tu fais ou

Parce que le source se trouve dans le fichier ftdi.c

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int ftdi_usb_open(struct ftdi_context *ftdi, int vendor, int product)
{
    return ftdi_usb_open_desc(ftdi, vendor, product, NULL, NULL);
}

Et toi tu lis trop vite,

Mais vu autrement, est-ce que vous vous prenez la tête quand vous avez au début de votre test.c qqchse genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
#include <stdio.h>
#include <time.h>

Hé bien là, dans le cas qui a suscité ce post c'était #include <ftdi.h> à la place de #include <time.h> et le compilo était censé aller chercher au même endroit, dans /usr/include/. Je ne vois vraiment pas ce qui a cloché sur ce coup-là...
Car quand je compile un test.c je n'ai pas besoin de générer avant un time.a ou un time.so, or, pour le compilateur, que le fichier s'appelle /usr/include/time.h ou /usr/include/ftdi.h, c'est pareil, non ?

'fin bon, l'un dans l'autre je m'en suis sorti comme ça :

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
gcc -Wall -L. -o ftdi.so /usr/include/ftdi.h
gcc -Wall -lftdi -L. -o simple simple.c

Est-ce que tu as installé cette bibliothèque avec "./configure; make; make install" ?

Que dalle ! Synaptic pour installer libftdi-dev et j'ai ensuite découvert un dossier examples où je suis allé fouiller

Édit: je me suis gouré c'est l minuscule pour la bibliothèque

Ah ben vi. Tu m'étonnes que je m'arrête contre un platane si tu me scies les freins

Merci à tous,

[foetus]

Hé bien là, dans le cas qui a suscité ce post c'était #include <ftdi.h> à la place de #include <time.h> et le compilo était censé aller chercher au même endroit, dans /usr/include/. Je ne vois vraiment pas ce qui a cloché sur ce coup-là...
Car quand je compile un test.c je n'ai pas besoin de générer avant un time.a ou un time.so, or, pour le compilateur, que le fichier s'appelle /usr/include/time.h ou /usr/include/ftdi.h, c'est pareil, non ?

Tu vois que tu captes que dalle

Parce que time fait parti de la bibliothèque standard et est livré avec le compilateur. Sa page officielle et Sa page wiki

Ton problème est bien l'emplacement des fichiers .a/ .so (que tu as compilé comme un bourrin à la racine )

D'ailleurs, il me semble que lorsque tu installes les paquets devel, tu installes que les .h et non pas les .a/ .so

Édit: j'ai perdu le paquet devel installe "/usr/lib/libftdi1.so" (ici)

Édit: Donc plus un gcc -lftdi1 -o simple simple.c.

[Jipété]

Tu vois que tu captes que dalle :

Jamais dit le contraire mais bon, compiler un helloworld même moi j'y arrive, d'habitude.
Même quand il y a plusieurs #include <fic.h> ou #include "autrefic.h".

Parce que time fait parti de la bibliothèque standard et est livré avec le compilateur. Sa page officielle et Sa page wiki

En quoi ça concerne le compilateur ? Ou bien le #include est avec les chevrons et il va chercher dans les chemins prédéfinis pour ça, ou bien c'est avec les doubles quotes et il va chercher là où c'est indiqué, point barre.
En l'espèce, je le redis, le ftdi.h se trouve avec stdio.h, time.h, etc., et je ne comprends pas pourquoi le compilo ne trouve pas dedans les fonctions dont il a besoin car appelées par le .c.

Dans ton cas, si le compilateur ne bronche pas, c'est parce que tu n’utilises que des fonctions/ procédures de cette bibliothèque ftdi. Par contre, si tu utilisais des constantes ou des structures, le compilateur aurait crié

Et toi tu expliques très mal : je ne veux me fâcher avec personne mais le compilateur a grave bronché : il m'a quand même envoyé une dizaine de lignes d'erreurs, toutes de la même forme que celle que j'ai donnée dans le 1^er post...

Mais le problème est bien l'emplacement des fichiers .a/ .so (que tu as compilé comme un bourrin à la racine )

Euh non, j'ai utilisé -L. et le "." signifie "là", "là où on est", c'est-à-dire dans le dossier où se trouvent les .c pour éviter de me compliquer la vie avec des chemins. Évidemment la vie se complique après...
Comme je dis toujours, "tu te dis que pour cette bricole t'en as pour 5 minutes et deux jours après t'y es encore"...
La preuve...

Bon, tout ça mis bout à bout me fait émettre l'hypothèse suivante : lors de ma première tentative de compilation, ce n'est pas ftdi.h que le compilo cherchait mais ftdi.a ou .so en fonction des params de la ldc, et il fallait donc en plus lui préciser -lftdi tout simplement et moi, bêtement, je pensais qu'avec ftdi.h en include ça lui suffisait et qu'il comprendrait et irait chercher tout seul le module, mais non...
Parce que je viens de refaire des tests, et le fait d'avoir généré .a et .so dans le dossier des .c ne sert à rien : je les ai virés, ça compile très bien à condition de ne pas oublier -lftdi !
Je fais trop peu de C pour me rappeler ce genre de chose tordue.
Bah, j'aurais appris quelque chose, allez, je vais jouer avec les binaires fraîchement générés

Bonne journée,

[foetus]

Ou bien le #include est avec les chevrons et il va chercher dans les chemins prédéfinis pour ça, ou bien c'est avec les doubles quotes et il va chercher là où c'est indiqué, point barre.

En théorie: chevrons -> les dossiers systèmes, les doubles quotes -> . le dossier où se trouve le source (local)

Mais tu peux mettre des chemins relatifs pour les 2

En l'espèce, je le redis, le ftdi.h se trouve avec stdio.h, time.h, etc., et je ne comprends pas pourquoi le compilo ne trouve pas dedans les fonctions dont il a besoin car appelées par le .c.

Parce que qu'il s'en cogne des .c

Le compilateur a besoin des .h pour avoir toutes les informations et le linker a besoin des .a/ .so

Et toi tu expliques très mal : je ne veux me fâcher avec personne mais le compilateur a grave bronché : il m'a quand même envoyé une dizaine de lignes d'erreurs, toutes de la même forme que celle que j'ai donnée dans le 1^er post...

Désolé, et j'ai retiré cette partie parce que j'ai eu un doute.

Et si ton compilateur râle, cela confirme mes doutes et la raison de la suppression

Euh non, j'ai utilisé -L. et le "." signifie "là", "là où on est", c'est-à-dire dans le dossier où se trouvent les .c pour éviter de me compliquer la vie avec des chemins. Évidemment la vie se complique après...

C'est normal et c'est ma première réponse.
C'est comme cela parce que c'est une librairie externe et cela à toujours été comme cela

Il n'y a qu'avec la librairie standard où tu n'as pas besoin de préciser quoi ce soit.

Et comme je l'ai dit, soit cette bibliothèque est installée dans ton système alors tu utilises les bascules -l et -L avec gcc.
Soit elle n'est pas installée et c'est à toi de compiler à la main avec tes sources.
Ou alors faire une bibliothèque statique pour une compilation à la main mais la réutiliser facilement.

Et c'est dans ces 2 derniers cas où tu as besoin des sources .c (et également lorsque tu installes cette bibliothèque avec un ".configure; make; make install" mais c'est transparent)

[Matt_Houston]

Je te recommande de changer de ton si tu comptes obtenir de l'aide supplémentaire du forum C.

La solution t'a été donnée dès la première réponse, certes accompagnée d'une petite erreur aisément décelable si tu avais pris la peine de consulter la documentation plutôt que d'ergoter sur trois pages. Au passage, l'inclusion de l'en-tête n'a jamais rien eu à faire dans l'histoire puisque dès le début c'est l'édition de liens qui échouait.

Il faut ensuite se référer à la documentation de ton compilateur pour savoir quelles options utiliser, voire de ton IDE pour savoir comment les lui transmettre. Il faut aussi se référer à la doc de la bibliothèque pour vérifier qu'elle n'offre pas un moyen simple pour récupérer les chemins (par exemple via pkg-config sous linux).

Je ne peux que te recommander d'utiliser un gestionnaire de projet (make ou autre …) qui te simplifiera grandement la vie.

Beaucoup de travail et de trafic et d'études pour trois misérables .c, le jeu n'en vaut pas la chandelle mais merci quand même d'avoir participé.

Sauf que dans le cas général c'est de cette manière que l'on crée un exécutable depuis un code C, que tu le veuilles ou non. Ces conseils sont les bons et si tu les avais appliqués tu aurais conservé un temps précieux (hint: il n'est pas trop tard).

[Médinoc]

Au fait, tu aurais pu dire dès le titre que ton "bête helloworld" était à propos de ftdi...

[Jipété]

Salut,

Au fait, tu aurais pu dire dès le titre que ton "bête helloworld" était à propos de ftdi...

oui, mais comme je l'ai dit dans le fil de la discussion, je fais trop peu de C pour avoir fait le rapprochement entre la librairie et le .h.

Dit autrement, voyant ce #include <ftdi.h>, je me suis bêtement dit que le compilo trouverait le .h quelque part dans /usr/include et basta, et je n'ai pas réussi à réfléchir plus loin.

Tu connais ftdi ?

[Médinoc]

Non, je ne connais pas ftdi, j'ai même du chercher sur Wikipédia pour savoir ce que le sigle voulait dire (apparemment c'est un fabriquant particulier de hardware USB, qui aime transformer les "imitations" en briques).
Tout ce que j'ai su, c'est que <ftdi.h> ni ftdi_usb_open() ne font partie du standard C, c'était donc une bibliothèque tierce (et donc, pas un "simple hello world" si simple que ça).

[foetus]

On l'utilise dans ma société. C'est un petit circuit imprimé pour connecter en USB nos produits en port COM.
Mais c'est transparent nos produits sont accessibles normalement en programmation COM

[Jipété]

(apparemment c'est un fabriquant particulier de hardware USB, qui aime transformer les "imitations" en briques).

On l'utilise dans ma société. C'est un petit circuit imprimé pour connecter en USB nos produits en port COM.
Mais c'est transparent nos produits sont accessibles normalement en programmation COM

Vous les achetez directement en Écosse ? Parce que sur le web, il semblerait qu'il y ait plein de fakes qui traînent, avec des bidouilles pour les faire fonctionner, c'est un peu tendu : juste en dessous de la photo, les entrées en noir sous la seconde note rouge...

[Médinoc]

C'est ce que Wikipédia dit, en tout cas;

[foetus]

Vous les achetez directement en Écosse ?

Soit le chip est directement intégré dans certain produit soit on vend un convertisseur (un peu gros) COM <-> USB (*)


* -> On en vendait, mais plus maintenant

[Jipété]

C'est ce que Wikipédia dit, en tout cas;

Je n'avais pas fait le rapprochement entre "imitations" et "fake". Zirak va me fusiller s'il passe par là...

Merci pour la précision que, oui, j'avais déjà lue.

C'est terrible ces histoires de fakes dans le monde industriel, y a même des fakes de transistors, truc de malade...