Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Gcc 5.30 sur Slackware-14.2

Aucune réponse
Avatar
Herve Autret
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 ?

à +
--
Hervé

10 réponses

1 2
Avatar
Jean-Marc Bourguet
Herve Autret writes:
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 ?
à +

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).
A+
--
Jean-Marc
FAQ de fclc++: http://web.archive.org/web/*/http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Avatar
Alain Ketterlin
Herve Autret writes:
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 ?

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.
-- Alain.
Avatar
Herve Autret
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 ?
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, mais :
- 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.
(Le fait que Slackware utilise une vraie lib dynamique -- apparemment --
ne change rien au problème je pense.)

Comme dit plus haut : avant, ça marchait(©)
Tu peux essayer de définir "int yylex() { return 0; }"...

Bien essayé, mais : pas mieux.
Mais à ce stade ça vaudrait le coup de faire l'effort de supprimer le
-lfl, puisque tu as déjà noyywrap.

Le problème c'est que je compile un truc que je n'ai pas écrit moi-même,
qui comporte une vingtaine de .l, qui utilise scons et qui marche encore
très bien chez les autres. Et pour modifier quelquechose, il faudrait
déjà que je trouve comment dire à scons de ne pas utiliser -lfl s'il y a
un main()...
Merci pour tes tests, ça me convainc de l'origine "compilo" du problème
à +
--
Hervé
Avatar
Herve Autret
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é.
à +
--
Hervé
Avatar
Jean-Marc Bourguet
Herve Autret writes:
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é.

Oops, j'avais pas vu. Ca ressemble à un bug quelque part, car avec des
versions légèrement différentes (celles d'Ubuntu 15.10) :
~/src]$ cat herve.l
%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;
}
[~/src]$ flex --version
flex 2.5.39
[~/src]$ gcc --version
gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[~/src]$ flex -oherve.cc herve.l
[~/src]$ g++ -o herve herve.cc -lfl
[~/src]$
A+
--
Jean-Marc
FAQ de fclc++: http://web.archive.org/web/*/http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Avatar
Alain Ketterlin
Herve Autret writes:
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 ?

Non, mais j'imagine que puisqu'elle doit faire office de .so il faut
qu'elle soit 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

Je penche plutot pour une config spécifique à Slackware.
- il y a bien un main() dans mon code : celui de la libfl ne devrait pas
être pris en compte...

Le message du linker indique qu'il cherche yylex, et la seule réfà ©rence
à yylex() vient du main de libfl.
Bon, mais je n'arrive pas à reproduire chez moi, avec des outils moins
récents.
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.

C'est forcément gcc ou ld. Essaie avec gcc -v (ou -###) pour voir la
commande de link.
[...]

-- Alain.
Avatar
Jean-Marc Bourguet
Alain Ketterlin writes:
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.

Pas nécessairement. Plus précisémenent, il y a deux aspects dans les .so:
- le fait qu'elle soit chargée dynamiquement (automatiquement au démarage
du programme ou à la demande avec dlopen)
- le fait qu'un seul exemplaire puisse être chargé en mémoire et partagé
entre différents processus.
Le PIC ne sert pas (du moins sous Linux) pour le premier aspect (et si j'ai
bonne mémoire il y a même un gain de perf à ne pas être PIC, au moins en 32
bits sur x86; d'autres jeux d'instructions peuvent permettre du code PIC
moins coûteux, et x86_64 doit avoir ce qu'il faut). Le système peut
charger en mémoire une .so avec du code non PIC et effectuer le même type
d'ajustements que pour un exécutable lié statiquement.
Le PIC sert pour le second aspect, les pages mémoires où le code est chargé
peuvent être mappées à différentes adresses dans différents processus sans
géner l'exécution du code (il faut quelques pages propres au processus pour
y mettre les infos propres au processus)
A+
--
Jean-Marc
FAQ de fclc++: http://web.archive.org/web/*/http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Avatar
Herve Autret
Bonjour,
Alain Ketterlin a écrit :
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
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-slackware-linux/5.3.0/lto-
wrapper
Target: x86_64-slackware-linux
Configured with: ../gcc-5.3.0/configure --prefix=/usr --libdir=/usr/lib64
--mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap
--enable-languages­a,c,c++,fortran,go,java,lto,objc --enable-
threads=posix --enable-checking=release --enable-objc-gc --with-system-
zlib --with-python-dir=/lib64/python2.7/site-packages --enable-libstdcxx-
dual-abi --with-default-libstdcxx-abi=gcc4-compatible --disable-libunwind-
exceptions --enable-__cxa_atexit --enable-libssp --enable-lto --disable-
install-libiberty --with-gnu-ld --verbose --enable-java-home --with-java-
home=/usr/lib64/jvm/jre --with-jvm-root-dir=/usr/lib64/jvm --with-jvm-jar-
dir=/usr/lib64/jvm/jvm-exports --with-arch-directory=amd64 --with-antlr-
jar=/root/slackware64-current/source/d/gcc/antlr-runtime-3.4.jar --enable-
java-awt=gtk --disable-gtktest --disable-multilib --target=x86_64-
slackware-linux --build=x86_64-slackware-linux --host=x86_64-slackware-
linux
Thread model: posix
gcc version 5.3.0 (GCC)
C'est dans ce qui précède ?
à +
--
Hervé
Avatar
Alain Ketterlin
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 dan s la
commande de link, pour qu'il affiche ce qu'il fait (ou devrait faire
avec -###).
Cela dit, en tapant betement le message dans google j'arrive à
http://lists.linuxfromscratch.org/pipermail/blfs-support/2015-April/076525. html
qui semble dire que c'est un problème de flex... La page de flex (et la
mailing list) ne semblent pas accessibles actuellement.
-- Alain.
Avatar
Alain Ketterlin
Alain Ketterlin writes:
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 -###).

[...]
L'idée de cette commande est de voir si le linker ne fait pas de zà ¨le
avec les symbols (du style -z now).
A part ça, tu as deux possibilités :
1) Passer l'option "-Wl,-unresolved-symbols=ignore-in-shared-libs" (ou
"-Wl,--warn-unresolved-symbols") au moment du link. Cela dit, si c'est
difficile d'enlever -lfl je ne vois pas pourquoi ce serait facile
d'ajouter une option...
2) ajouter la déclaration suivante dans ton code :
extern "C" { int yylex() { return 0; } }
Je t'avais déjà proposé cela, mais sans le extern "C", ce qu i ne pouvait
pas marcher. Cela devrait satisfaire le linker, et ce ne sera jamais
utilisé de toute façon.
-- Alain.
1 2