Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage C++ Gcc 5.30 sur Slackware-14.2

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é
Signaler un problème avec ce contenu

8 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Herve Autret
Bonjour,
Alain Ketterlin a écrit :
Non. J'aurais du préciser : il faut passer cette option à gcc dans la
commande de link, pour qu'il affiche ce qu'il fait (ou devrait faire
avec -###).


O'kkkaayyy !
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).

Selon ton message précédent, la balle est dans le camp de Flex, mais
pour la forme, voici le résultat avec le code non modifié (échec) :
g++ -v -o linkPlus linkPlus.o -lfl
Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/specs
COLLECT_GCC=g++
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)
COMPILER_PATH=/usr/libexec/gcc/x86_64-slackware-linux/5.3.0/:/usr/libexec/
gcc/x86_64-slackware-linux/5.3.0/:/usr/libexec/gcc/x86_64-slackware-
linux/:/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/:/usr/lib64/gcc/x86_64-
slackware-linux/:/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../
x86_64-slackware-linux/bin/
LIBRARY_PATH=/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/:/usr/lib64/gcc/
x86_64-slackware-linux/5.3.0/../../../../lib64/:/lib/../lib64/:/usr/
lib/../lib64/:/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../
x86_64-slackware-linux/lib/:/usr/lib64/gcc/x86_64-slackware-
linux/5.3.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'linkPlus' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/libexec/gcc/x86_64-slackware-linux/5.3.0/collect2 -plugin /usr/
libexec/gcc/x86_64-slackware-linux/5.3.0/liblto_plugin.so -plugin-opt=/
usr/libexec/gcc/x86_64-slackware-linux/5.3.0/lto-wrapper -plugin-opt=-
fresolution=/tmp/ccbz93d5.res -plugin-opt=-pass-through=-lgcc_s -plugin-
opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-
through=-lgcc_s -plugin-opt=-pass-through=-lgcc --eh-frame-hdr -m
elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o linkPlus /usr/
lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../lib64/crt1.o /usr/
lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../lib64/crti.o /usr/
lib64/gcc/x86_64-slackware-linux/5.3.0/crtbegin.o -L/usr/lib64/gcc/x86_64-
slackware-linux/5.3.0 -L/usr/lib64/gcc/x86_64-slackware-
linux/5.3.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/
lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../x86_64-slackware-linux/
lib -L/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../.. linkPlus.o -lfl
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib64/gcc/x86_64-
slackware-linux/5.3.0/crtend.o /usr/lib64/gcc/x86_64-slackware-
linux/5.3.0/../../../../lib64/crtn.o
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../lib64/libfl.so:
undefined reference to `yylex'
collect2: error: ld returned 1 exit status
Makefile:19: recipe for target 'linkPlus' failed
make: *** [linkPlus] Error 1
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...

Pas plus que d'appliquer la solution proposée sur
lists.linuxfromscratch.org, en effet.
2) ajouter la déclaration suivante dans ton code :
extern "C" { int yylex() { return 0; } }

Super : là, ça fonctionne. Merci !
Cela devrait satisfaire le linker, et ce ne sera jamais
utilisé de toute façon.

Donc ça marchera aussi chez les copains.
Encore un grand merci.
--
Hervé
Avatar
Herve Autret
Bonjour,
Jean-Marc Bourguet a écrit :
[libfl]

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[:] il y a deux aspects dans les .so:
[...]
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)

Merci pour ce rappel qui ne fait pas de mal.
à +
--
Hervé
Avatar
Herve Autret
Bonjour
Alain Ketterlin a écrit :
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.

Là, ça venait de moi : j'ai confondu la plate-forme PIC et l'option de
compilation (mais tu avais peut-être compris)...
M'étonnait quelque peu, quand même, une libfl sur un PIC...
à +
--
Hervé
Avatar
Alain Ketterlin
Herve Autret writes:
Selon ton message précédent, la balle est dans le camp de Flex, mais
pour la forme, voici le résultat avec le code non modifié (à ©chec) :
g++ -v -o linkPlus linkPlus.o -lfl
Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/specs
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-slackware-linux/5.3.0/lto-
wrapper

[...]
Ah, il y a peut-etre une piste : il se peut que lto (link-time
optimization) réclame que tous les symboles soient définis (en g énéral
c'est l'inverse mais bon). Si tu y tiens, tu peux essayer de
compiler/linker avec -fno-lto
2) ajouter la déclaration suivante dans ton code :
extern "C" { int yylex() { return 0; } }

Super : là, ça fonctionne.

Donc, noter et faire passer le mot : mort à libfl (chez moi, 18 octets
de code pour main et 6 octets pour yywrap, et c'est tout).
-- Alain.
Avatar
Herve Autret
Bonjour,
Alain Ketterlin :
Ah, il y a peut-etre une piste : il se peut que lto (link-time
optimization) réclame que tous les symboles soient définis (en général
c'est l'inverse mais bon). Si tu y tiens, tu peux essayer de
compiler/linker avec -fno-lto

Essayé : pas mieux.
Donc, noter et faire passer le mot : mort à libfl (chez moi, 18 octets
de code pour main et 6 octets pour yywrap, et c'est tout).

C'est pourtant bien pratique, quand on n'a pas le temps
de copier/coller un main() et un yywrap() ;-)
Mais comme de l'autre côté il suffit de coller une ligne "export..."
dans l'en-tête du fichier lex, la balance penche bien de ton côté.
Même l'option c++ pourrait se trouver sur la sellette,
d'après le code produit :
/* The c++ scanner is a mess[ because...] We will address this
* in a future release of flex, or omit the C++ scanner altogether. */
à +
--
Hervé
Avatar
Alain Ketterlin
Herve Autret writes:
Ah, il y a peut-etre une piste : il se peut que lto (link-time
optimization) réclame que tous les symboles soient définis (en général
c'est l'inverse mais bon). Si tu y tiens, tu peux essayer de
compiler/linker avec -fno-lto

Essayé : pas mieux.

Bon, alors admettons que ce mystère nous dépasse...
Donc, noter et faire passer le mot : mort à libfl (chez moi, 18 oct ets
de code pour main et 6 octets pour yywrap, et c'est tout).

C'est pourtant bien pratique, quand on n'a pas le temps
de copier/coller un main() et un yywrap() ;-)

Les voici pour ceux qui n'ont pas le temps de les écrire :
int yywrap() { return 1; }
int main() { while (yylex()); return 0; }
La première est avantageusement remplacée par %option noyywrap (s i il
faut lire plusieurs fichiers, il faut de toute façon en faire une
version spécialisée). La seconde a peu de chance de servir à quoi que ce
soit d'autre que débugger l'analyseur lexical.
Même l'option c++ pourrait se trouver sur la sellette,
d'après le code produit :
/* The c++ scanner is a mess[ because...] We will address this
* in a future release of flex, or omit the C++ scanner altogether. */

Bon, ne le répète à personne, mais cela fait des années que je compile
en C++ des analyseurs générés en C (par flex et par bison). Cela demande
un peu de gymnastique pour les valeurs lexicale et sémantique, mais ri en
de dramatique. Je le déconseille seulement pour le principe.
-- Alain.
Avatar
Herve Autret
Bonjour,
Alain Ketterlin :
Les voici pour ceux qui n'ont pas le temps de les écrire :
int yywrap() { return 1; }
int main() { while (yylex()); return 0; }

Un grand merci de leur part.
Bon, ne le répète à personne, mais cela fait des années que je compile
en C++ des analyseurs générés en C (par flex et par bison). Cela demande
un peu de gymnastique pour les valeurs lexicale et sémantique, mais rien
de dramatique. Je le déconseille seulement pour le principe.

Comme plus personne ne lit Usenet, ça restera entre nous.
--
Hervé
Avatar
Olivier Miakinen
Le 22/07/2016 14:55, Herve Autret a écrit :
Bon, ne le répète à personne, mais cela fait des années que je compile
en C++ des analyseurs générés en C (par flex et par bison). Cela demande
un peu de gymnastique pour les valeurs lexicale et sémantique, mais rien
de dramatique. Je le déconseille seulement pour le principe.

Comme plus personne ne lit Usenet, ça restera entre nous.

:-D
--
Olivier Miakinen
1 2