Bonjour,
J'ai des problèmes pour obtenir un exécutable à partir d'un source Lex
sur cette distro.
gcc 5.30
flex 2.6.0
Le source (linkPlus.l, disons)
%-------------
%option c++
%option noyywrap
%{
#include <iostream>
using namespace std;
#include <cstdio> // pour EOF
int mylineno = 0;
%}
%%
%%
int main (void) {
FlexLexer* lexer = new yyFlexLexer;
while(lexer->yylex() != 0)
;
return 0;
}
%-----------------
La commande de compilation :
flex -olinkPlus.cc linkPlus.l
La mauvaise commande d'édition de liens :
g++ -o linkPlus linkPlus.cc -lfl
Le résultat :
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../lib64/libfl.so:
undefined reference to `yylex'
La bonne commande d'édition :
g++ -o linkPlus linkPlus.cc
Y a-t-il un moyen d'éviter que le fait de préciser la bibliothèque libfl
ne fasse rater la manoeuvre ?
à +
Bonjour,
J'ai des problèmes pour obtenir un exécutable à partir d'un source Lex
sur cette distro.
gcc 5.30
flex 2.6.0
Le source (linkPlus.l, disons)
%-------------
%option c++
%option noyywrap
%{
#include <iostream>
using namespace std;
#include <cstdio> // pour EOF
int mylineno = 0;
%}
%%
%%
int main (void) {
FlexLexer* lexer = new yyFlexLexer;
while(lexer->yylex() != 0)
;
return 0;
}
%-----------------
La commande de compilation :
flex -olinkPlus.cc linkPlus.l
La mauvaise commande d'édition de liens :
g++ -o linkPlus linkPlus.cc -lfl
Le résultat :
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../lib64/libfl.so:
undefined reference to `yylex'
La bonne commande d'édition :
g++ -o linkPlus linkPlus.cc
Y a-t-il un moyen d'éviter que le fait de préciser la bibliothèque libfl
ne fasse rater la manoeuvre ?
à +
Bonjour,
J'ai des problèmes pour obtenir un exécutable à partir d'un source Lex
sur cette distro.
gcc 5.30
flex 2.6.0
Le source (linkPlus.l, disons)
%-------------
%option c++
%option noyywrap
%{
#include <iostream>
using namespace std;
#include <cstdio> // pour EOF
int mylineno = 0;
%}
%%
%%
int main (void) {
FlexLexer* lexer = new yyFlexLexer;
while(lexer->yylex() != 0)
;
return 0;
}
%-----------------
La commande de compilation :
flex -olinkPlus.cc linkPlus.l
La mauvaise commande d'édition de liens :
g++ -o linkPlus linkPlus.cc -lfl
Le résultat :
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../lib64/libfl.so:
undefined reference to `yylex'
La bonne commande d'édition :
g++ -o linkPlus linkPlus.cc
Y a-t-il un moyen d'éviter que le fait de préciser la bibliothèque libfl
ne fasse rater la manoeuvre ?
à +
gcc 5.30
flex 2.6.0
%option c++
%option noyywrap
%{
#include <iostream>
using namespace std;
#include <cstdio> // pour EOF
int mylineno = 0;
%}
%%
%%
int main (void) {
FlexLexer* lexer = new yyFlexLexer;
while(lexer->yylex() != 0)
;
return 0;
}
flex -olinkPlus.cc linkPlus.l
La mauvaise commande d'édition de liens :
g++ -o linkPlus linkPlus.cc -lfl
Le résultat :
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../lib64/libfl.so:
undefined reference to `yylex'
La bonne commande d'édition :
g++ -o linkPlus linkPlus.cc
Y a-t-il un moyen d'éviter que le fait de préciser la biblioth èque libfl
ne fasse rater la manoeuvre ?
gcc 5.30
flex 2.6.0
%option c++
%option noyywrap
%{
#include <iostream>
using namespace std;
#include <cstdio> // pour EOF
int mylineno = 0;
%}
%%
%%
int main (void) {
FlexLexer* lexer = new yyFlexLexer;
while(lexer->yylex() != 0)
;
return 0;
}
flex -olinkPlus.cc linkPlus.l
La mauvaise commande d'édition de liens :
g++ -o linkPlus linkPlus.cc -lfl
Le résultat :
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../lib64/libfl.so:
undefined reference to `yylex'
La bonne commande d'édition :
g++ -o linkPlus linkPlus.cc
Y a-t-il un moyen d'éviter que le fait de préciser la biblioth èque libfl
ne fasse rater la manoeuvre ?
gcc 5.30
flex 2.6.0
%option c++
%option noyywrap
%{
#include <iostream>
using namespace std;
#include <cstdio> // pour EOF
int mylineno = 0;
%}
%%
%%
int main (void) {
FlexLexer* lexer = new yyFlexLexer;
while(lexer->yylex() != 0)
;
return 0;
}
flex -olinkPlus.cc linkPlus.l
La mauvaise commande d'édition de liens :
g++ -o linkPlus linkPlus.cc -lfl
Le résultat :
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../lib64/libfl.so:
undefined reference to `yylex'
La bonne commande d'édition :
g++ -o linkPlus linkPlus.cc
Y a-t-il un moyen d'éviter que le fait de préciser la biblioth èque libfl
ne fasse rater la manoeuvre ?
Y a-t-il un moyen d'éviter que le fait de préciser la bibliothèque
libfl ne fasse rater la manoeuvre ?
Aucune idée, mais chez moi libfl.so est un script qui renvoie a une lib
statique (libfl_pic.a), laquelle ne contient que deux choses : yywrap(),
et un main() qui appelle yylex().
C'est le second qui manifestement pose
problème, puisque le code produit par flex en c++ ne contient pas de
fonction yylex().
(Le fait que Slackware utilise une vraie lib dynamique -- apparemment --
ne change rien au problème je pense.)
Tu peux essayer de définir "int yylex() { return 0; }"...
Mais à ce stade ça vaudrait le coup de faire l'effort de supprimer le
-lfl, puisque tu as déjà noyywrap.
Y a-t-il un moyen d'éviter que le fait de préciser la bibliothèque
libfl ne fasse rater la manoeuvre ?
Aucune idée, mais chez moi libfl.so est un script qui renvoie a une lib
statique (libfl_pic.a), laquelle ne contient que deux choses : yywrap(),
et un main() qui appelle yylex().
C'est le second qui manifestement pose
problème, puisque le code produit par flex en c++ ne contient pas de
fonction yylex().
(Le fait que Slackware utilise une vraie lib dynamique -- apparemment --
ne change rien au problème je pense.)
Tu peux essayer de définir "int yylex() { return 0; }"...
Mais à ce stade ça vaudrait le coup de faire l'effort de supprimer le
-lfl, puisque tu as déjà noyywrap.
Y a-t-il un moyen d'éviter que le fait de préciser la bibliothèque
libfl ne fasse rater la manoeuvre ?
Aucune idée, mais chez moi libfl.so est un script qui renvoie a une lib
statique (libfl_pic.a), laquelle ne contient que deux choses : yywrap(),
et un main() qui appelle yylex().
C'est le second qui manifestement pose
problème, puisque le code produit par flex en c++ ne contient pas de
fonction yylex().
(Le fait que Slackware utilise une vraie lib dynamique -- apparemment --
ne change rien au problème je pense.)
Tu peux essayer de définir "int yylex() { return 0; }"...
Mais à ce stade ça vaudrait le coup de faire l'effort de supprimer le
-lfl, puisque tu as déjà noyywrap.
%option c++
Essaye avec
flex --c++ -olinkPlus.cc linkPlus.l
pour dire à flex de générer du C++ (mais je m'étonne de l'absence
d'erreurs avant si c'est bien la solution).
%option c++
Essaye avec
flex --c++ -olinkPlus.cc linkPlus.l
pour dire à flex de générer du C++ (mais je m'étonne de l'absence
d'erreurs avant si c'est bien la solution).
%option c++
Essaye avec
flex --c++ -olinkPlus.cc linkPlus.l
pour dire à flex de générer du C++ (mais je m'étonne de l'absence
d'erreurs avant si c'est bien la solution).
Bonjour,
Jean-Marc Bourguet a écrit :%option c++
Essaye avec
flex --c++ -olinkPlus.cc linkPlus.l
pour dire à flex de générer du C++ (mais je m'étonne de l'absence
d'erreurs avant si c'est bien la solution).
En fait la ligne "%option c++" du code flex lui dit déjà de produire du C+
+, donc il n'y a pas d'amélioration.
Flex aurait pu avoir un bug à ce niveau, note, donc merci d'avoir essayé.
Bonjour,
Jean-Marc Bourguet a écrit :
%option c++
Essaye avec
flex --c++ -olinkPlus.cc linkPlus.l
pour dire à flex de générer du C++ (mais je m'étonne de l'absence
d'erreurs avant si c'est bien la solution).
En fait la ligne "%option c++" du code flex lui dit déjà de produire du C+
+, donc il n'y a pas d'amélioration.
Flex aurait pu avoir un bug à ce niveau, note, donc merci d'avoir essayé.
Bonjour,
Jean-Marc Bourguet a écrit :%option c++
Essaye avec
flex --c++ -olinkPlus.cc linkPlus.l
pour dire à flex de générer du C++ (mais je m'étonne de l'absence
d'erreurs avant si c'est bien la solution).
En fait la ligne "%option c++" du code flex lui dit déjà de produire du C+
+, donc il n'y a pas d'amélioration.
Flex aurait pu avoir un bug à ce niveau, note, donc merci d'avoir essayé.
Bonjour,
Alain Ketterlin a écrit :Y a-t-il un moyen d'éviter que le fait de préciser la bibliot hèque
libfl ne fasse rater la manoeuvre ?
Aucune idée, mais chez moi libfl.so est un script qui renvoie a une lib
statique (libfl_pic.a), laquelle ne contient que deux choses : yywrap(),
et un main() qui appelle yylex().
Tu fais tourner ça sur du Pic ?
C'est le second qui manifestement pose problème, puisque le code
produit par flex en c++ ne contient pas de fonction yylex().
Ãa pourrait tenir à ça, parce que flex marche pour le C, m ais :
- Ce fichier donne un exé en C++ avec gcc-4.7.1 et flex-2.5.35, qu' on
spécifie -lfl ou non, et il marchait aussi avec gcc-4.8
- il y a bien un main() dans mon code : celui de la libfl ne devrait pas
être pris en compte...
En fait ce serait peut-être le couple gcc/ld qui est en cause.
Gcc-6 est sorti ; s'il ne résoud pas le pb je peux rétrograder vers le
4.7.1 pour voir.
[...]
Bonjour,
Alain Ketterlin a écrit :
Y a-t-il un moyen d'éviter que le fait de préciser la bibliot hèque
libfl ne fasse rater la manoeuvre ?
Aucune idée, mais chez moi libfl.so est un script qui renvoie a une lib
statique (libfl_pic.a), laquelle ne contient que deux choses : yywrap(),
et un main() qui appelle yylex().
Tu fais tourner ça sur du Pic ?
C'est le second qui manifestement pose problème, puisque le code
produit par flex en c++ ne contient pas de fonction yylex().
Ãa pourrait tenir à ça, parce que flex marche pour le C, m ais :
- Ce fichier donne un exé en C++ avec gcc-4.7.1 et flex-2.5.35, qu' on
spécifie -lfl ou non, et il marchait aussi avec gcc-4.8
- il y a bien un main() dans mon code : celui de la libfl ne devrait pas
être pris en compte...
En fait ce serait peut-être le couple gcc/ld qui est en cause.
Gcc-6 est sorti ; s'il ne résoud pas le pb je peux rétrograder vers le
4.7.1 pour voir.
[...]
Bonjour,
Alain Ketterlin a écrit :Y a-t-il un moyen d'éviter que le fait de préciser la bibliot hèque
libfl ne fasse rater la manoeuvre ?
Aucune idée, mais chez moi libfl.so est un script qui renvoie a une lib
statique (libfl_pic.a), laquelle ne contient que deux choses : yywrap(),
et un main() qui appelle yylex().
Tu fais tourner ça sur du Pic ?
C'est le second qui manifestement pose problème, puisque le code
produit par flex en c++ ne contient pas de fonction yylex().
Ãa pourrait tenir à ça, parce que flex marche pour le C, m ais :
- Ce fichier donne un exé en C++ avec gcc-4.7.1 et flex-2.5.35, qu' on
spécifie -lfl ou non, et il marchait aussi avec gcc-4.8
- il y a bien un main() dans mon code : celui de la libfl ne devrait pas
être pris en compte...
En fait ce serait peut-être le couple gcc/ld qui est en cause.
Gcc-6 est sorti ; s'il ne résoud pas le pb je peux rétrograder vers le
4.7.1 pour voir.
[...]
Herve Autret writes:Bonjour,
Alain Ketterlin a écrit :Y a-t-il un moyen d'éviter que le fait de préciser la bibliothèque
libfl ne fasse rater la manoeuvre ?
Aucune idée, mais chez moi libfl.so est un script qui renvoie a une lib
statique (libfl_pic.a), laquelle ne contient que deux choses : yywrap(),
et un main() qui appelle yylex().
Tu fais tourner ça sur du Pic ?
Non, mais j'imagine que puisqu'elle doit faire office de .so il faut
qu'elle soit pic.
Herve Autret <autreh@alussinan.org> writes:
Bonjour,
Alain Ketterlin a écrit :
Y a-t-il un moyen d'éviter que le fait de préciser la bibliothèque
libfl ne fasse rater la manoeuvre ?
Aucune idée, mais chez moi libfl.so est un script qui renvoie a une lib
statique (libfl_pic.a), laquelle ne contient que deux choses : yywrap(),
et un main() qui appelle yylex().
Tu fais tourner ça sur du Pic ?
Non, mais j'imagine que puisqu'elle doit faire office de .so il faut
qu'elle soit pic.
Herve Autret writes:Bonjour,
Alain Ketterlin a écrit :Y a-t-il un moyen d'éviter que le fait de préciser la bibliothèque
libfl ne fasse rater la manoeuvre ?
Aucune idée, mais chez moi libfl.so est un script qui renvoie a une lib
statique (libfl_pic.a), laquelle ne contient que deux choses : yywrap(),
et un main() qui appelle yylex().
Tu fais tourner ça sur du Pic ?
Non, mais j'imagine que puisqu'elle doit faire office de .so il faut
qu'elle soit pic.
C'est forcément gcc ou ld. Essaie avec gcc -v (ou -###) pour voir la
commande de link.
C'est forcément gcc ou ld. Essaie avec gcc -v (ou -###) pour voir la
commande de link.
C'est forcément gcc ou ld. Essaie avec gcc -v (ou -###) pour voir la
commande de link.
C'est forcément gcc ou ld. Essaie avec gcc -v (ou -###) pour voir la
commande de link.
Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/specs
C'est dans ce qui précède ?
C'est forcément gcc ou ld. Essaie avec gcc -v (ou -###) pour voir la
commande de link.
Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/specs
C'est dans ce qui précède ?
C'est forcément gcc ou ld. Essaie avec gcc -v (ou -###) pour voir la
commande de link.
Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/specs
C'est dans ce qui précède ?
Herve Autret writes:C'est forcément gcc ou ld. Essaie avec gcc -v (ou -###) pour voir la
commande de link.
Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/specs
[...]C'est dans ce qui précède ?
Non. J'aurais du préciser : il faut passer cette option à gcc d ans la
commande de link, pour qu'il affiche ce qu'il fait (ou devrait faire
avec -###).
Herve Autret <autreh@alussinan.org> writes:
C'est forcément gcc ou ld. Essaie avec gcc -v (ou -###) pour voir la
commande de link.
Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/specs
[...]
C'est dans ce qui précède ?
Non. J'aurais du préciser : il faut passer cette option à gcc d ans la
commande de link, pour qu'il affiche ce qu'il fait (ou devrait faire
avec -###).
Herve Autret writes:C'est forcément gcc ou ld. Essaie avec gcc -v (ou -###) pour voir la
commande de link.
Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/specs
[...]C'est dans ce qui précède ?
Non. J'aurais du préciser : il faut passer cette option à gcc d ans la
commande de link, pour qu'il affiche ce qu'il fait (ou devrait faire
avec -###).