Variables globales non déclarées et 'extern'

Version imprimable

02/09/2011, 15h29
TomTom68

Variables globales non déclarées et 'extern'

Bonjour,

J'utilise cygwin pour compiler du code pour core linux 2.6.13.

Je viens encore de vivre un problème récurrent chez moi, vieillesse oblige :

Je crée dans un header (.h) une variable, genre :

extern int toto;

et j'oublie malencontreusement de la déclarer en tant que variable globale dans le fichier source (.c).

Mes options de compilation sont les suivantes :
CFLAGS = -std=c99 -W -Wall -O2 -fPIC -pedantic -Os
LDFLAGS = -ldl -shared

Lorsque je compile, je ne vois aucune erreur apparaitre et ce n'est qu'au plantage de mon appli que je me rend compte de l'oubli de déclaration.

Je ne trouve pas quoi mettre en place pour faire apparaitre cette erreur dans les options de compilation.

Merci pour votre aide.
02/09/2011, 21h19
ram-0000

Je suis surpris qu'il n'y ait pas d'erreur lors du link genre "undefined reference to toto"
02/09/2011, 23h16
Obsidian

Tu utilises quoi pour compiler ton application ?

Si LDFLAGS est passé à GCC d'une manière ou d'une autre, ou que tu crées un fichier objet transformé ensuite en exécutable par ld, alors le flag « -shared » devrait te créer une bibliothèque dynamique. Il n'y aurait donc pas de contre-indication à continuer à utiliser une variable globale externe.

Ce qui est curieux, c'est que tu aies pu lancer ton application.
03/09/2011, 11h36
TomTom68

Je sais, je suis le premier surpris que ça marche, mais c'est ainsi. De plus, cela fait 15 jours que ça marche avec plein de changements dans le code, d'ajouts, de retraits, ça ne plante jamais, ça ne doit donc pas être un coup de chance sur une zone mémoire correcte par hasard.

Je suis un peu à la bourre, mais je prépare d'ici fin du WE un bout de code complet pour que quelqu'un essaye de compiler chez lui et voir si ça marche ou non, si le phénomène se reproduit ou non.

Cordialement.

Voici un code qui accepte la compilation sans erreur alors que la variable extern 'test' n'est pas déclarée.

hook.h

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
#ifndef _HOOK_H
#define _HOOK_H
 
#define _GNU_SOURCE
#include <stdlib.h>
#include <dlfcn.h>
#include <stdarg.h>
 
#define _HIDDEN_ \
	__attribute__( ( visibility( "hidden" ) ) )
 
#define _CONSTRUCTOR_ \
	__attribute__( ( constructor ) ) _HIDDEN_
 
#define _DESTRUCTOR_ \
	__attribute__( ( destructor ) ) _HIDDEN_
 
typedef int (*_open)(const char *, int, ...);
 
_CONSTRUCTOR_ void hook_init( void );
_DESTRUCTOR_ void hook_uninit( void );
 
extern int test;
 
#endif

hook.c

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#include "hook.h"
 
static _open	hook_open;
 
void hook_init( void ) {
}
 
void hook_uninit( void ) {
}
 
int open( const char *pathname, int flags, ... ) {
int ret;
va_list ap;
 
	if ( !hook_open ) {
		hook_open = (_open)dlsym( RTLD_NEXT, "open" );
	}
	va_start( ap, flags );
	ret = hook_open( pathname, flags, va_arg( ap, mode_t ) );
	va_end( ap );
 
	return ret;
}

makefile

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
EXEC	= Test.so
CC		= /usr/local/cross/gcc-3.3.4_glibc-2.3.2/arm-linux/bin/gcc
CFLAGS	= -std=c99 -W -Wall -O2 -fPIC -pedantic -Os
LDFLAGS	= -ldl -shared -lm
OBJDIR	= obj
BINDIR	= bin
SRC		= $(wildcard *.c)
OBJS	= $(SRC:.c=.o)
HEADERS	= $(wildcard *.h)
OBJS2	:= $(addprefix $(OBJDIR)/, $(OBJS))
 
.PHONY: clean, install
 
all: $(EXEC)
 
$(EXEC): $(OBJS)
	@mkdir -p $(BINDIR)
	@$(CC) $(LDFLAGS) $(OBJS2) -o $(BINDIR)/$(EXEC)
 
%.o:%.c
	@mkdir -p $(OBJDIR)
	@$(CC) $(CFLAGS) -c $< -o $(OBJDIR)/$@
 
clean:
	@$(RM) $(BINDIR)/$(EXEC) $(OBJS2)

Et un autre bug en prime :

Je peux relancer 100x la compilation, mon makefile ne détecte pas que les fichier .o sont déjà créés pour la source en cours et qu'elle n'a pas été modifié.
Je ne sais pas si c'est lié à mon souci, mais je préfère en parler, on ne sait jamais. Comme je ne suis pas un dieu en makefile, je compte un peu sur vous tous.

Merci.

03/09/2011, 22h05
Obsidian

Bon, je viens d'essayer chez moi et, sans surprise, ton code produit une bibliothèque partagée reconnue comme telle par la commande file.

Quand j'essaie de la lancer comme un exécutable, pas de complainte, mais une segfault. Cela dit, j'obtiens exactement le même comportement quand j'essaie de lancer une bibliothèque au hasard dans /usr/lib ou /usr/lib64. Donc, ce comportement (le fait de pouvoir lancer ta lib) n'est pas dû à ton code.

Citation:

Je peux relancer 100x la compilation, mon makefile ne détecte pas que les fichier .o sont déjà créés pour la source en cours et qu'elle n'a pas été modifié.
Je ne sais pas si c'est lié à mon souci, mais je préfère en parler, on ne sait jamais. Comme je ne suis pas un dieu en makefile, je compte un peu sur vous tous.

C'est normal : tu crées tes fichiers objets dans un sous-répertoire sans t'y trouver. Et comme le chemin n'est pas précisé dans les noms de cible, il n'y a aucune chance pour que le Makefile les voie.

Citation:

Envoyé par TomTom68

Voici un code qui accepte la compilation sans erreur alors que la variable extern 'test' n'est pas déclarée.

hook.h

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
#ifndef _HOOK_H
#define _HOOK_H
 
#define _GNU_SOURCE
#include <stdlib.h>
#include <dlfcn.h>
#include <stdarg.h>
 
#define _HIDDEN_ \
	__attribute__( ( visibility( "hidden" ) ) )
 
#define _CONSTRUCTOR_ \
	__attribute__( ( constructor ) ) _HIDDEN_
 
#define _DESTRUCTOR_ \
	__attribute__( ( destructor ) ) _HIDDEN_
 
typedef int (*_open)(const char *, int, ...);
 
_CONSTRUCTOR_ void hook_init( void );
_DESTRUCTOR_ void hook_uninit( void );
 
extern int test;
 
#endif

hook.c

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#include "hook.h"
 
static _open	hook_open;
 
void hook_init( void ) {
}
 
void hook_uninit( void ) {
}
 
int open( const char *pathname, int flags, ... ) {
int ret;
va_list ap;
 
	if ( !hook_open ) {
		hook_open = (_open)dlsym( RTLD_NEXT, "open" );
	}
	va_start( ap, flags );
	ret = hook_open( pathname, flags, va_arg( ap, mode_t ) );
	va_end( ap );
 
	return ret;
}

Salut
C'est normal: tu ne fais jamais référence à ta variable "test"

Rajoute ceci dans ton code...

Code:

1
2
3
int main(){
	test=0;
}

... et tente de recompiler en demandant une édition de liens...

04/09/2011, 13h28
TomTom68

Citation de Sve@r:

Citation:

C'est normal: tu ne fais jamais référence à ta variable "test"

Désolé, mais avec ou sans appel de la variable, le même phénomène se produit.

Il y a même pire, je viens de le vivre à l'instant : si je déclare une fonction :
int toto();
dans un header (pas de extern dans cet exemple, c'est volontaire) et si je me trompe dans la déclaration de la véritable fonction, que je l'utilise ou non :
int tata();
dans le source code, le compilateur ne voit rien, ne dit rien !

AU SECOURS !!!
Si gcc sous cygwin est une telle passoire, quelle est son utilité ?!

J'espère que c'est juste une erreur de makefile de ma part !

Merci pour votre aide car je ne vois toujours pas de solution à ça, que ce soit variable ou fonction.
04/09/2011, 13h58
Obsidian

Citation:

Envoyé par TomTom68

Il y a même pire, je viens de le vivre à l'instant : si je déclare une fonction : int toto(); dans un header (pas de extern dans cet exemple, c'est volontaire) et si je me trompe dans la déclaration de la véritable fonction, que je l'utilise ou non :int tata(); dans le source code, le compilateur ne voit rien, ne dit rien !

C'est normal, tu es toujours, à ce que je sache, en train de produire une bibliothèque dynamique (avec -shared) plutôt qu'un exécutable et ce, même si elle contient une fonction main(), traitée ici comme une fonction ordinaire.

On ne met pas « extern » devant une déclaration de fonction car cette dernière n'est jamais instanciée comme l'est une variable. Du coup, le prototype suffit à expliquer au compilateur comment on l'utilise. La définition d'une fonction vaut donc déclaration, pour autant qu'on ne s'y réfère pas en amont.

Donc, pour le compilo, tu fais deux choses distinctes :
— Tu l'informes de l'existence d'une fonction « int toto() », où qu'elle soit, qui n'attend aucun argument mais qui renvoie un int. Et si tu ne l'utilise pas, c'est encore mieux ;
— Tu définis par ailleurs une autre fonction « tata() » dont la signature est similaire, mais qui n'en reste pas moins une fonction distincte.

Et de là :

— Tu n'utilises aucune de ces fonctions ? Très bien.
— Tu utilises une fonction dont le nom n'est pas tout-à-fait le même ? Pas de problème, c'est une bibliothèque, la référence se fera à l'édition des liens, ou par le chargeur dynamique ;
— Tu définis des fonctions non utilisées ? Pas de problème, ça reste du code, et c'est toujours une bibliothèque dynamique : par définition, elles seront exploitées par du code extérieur à ton projet.
04/09/2011, 19h25
TomTom68

Et ben voilà !
Quand on me prend par la main et qu'on m'explique simplement, je finis par comprendre...

Ok, ok, ok ok. Donc tout ce que je structure ici, je ferais mieux de le tester dans un exécutable et lorsque tout est débugger et stable, je réintroduis dans la lib. C'est acceptable comme méthodologie de conception et validation ?

En tout cas, merci pour les explications, je finissais par ne plus savoir quoi penser, je n'avais pas fait le lien une seule seconde avec le dynamisme de la lib.

Merci Obsidian.
04/09/2011, 19h38
Obsidian

Citation:

Envoyé par TomTom68

Ok, ok, ok ok. Donc tout ce que je structure ici, je ferais mieux de le tester dans un exécutable et lorsque tout est débugger et stable, je réintroduis dans la lib. C'est acceptable comme méthodologie de conception et validation ?

En matière de conception, il vaut mieux te donner des règles en amont (même si les codeurs, comme moi, préfèrent en général se ruer directement sur le code).

Côté validation, le mieux est de faire une « test suite » dans un répertoire donné et d'écrire des tests unitaires. Dans ce répertoire, tu crées une série d'exécutables minimalistes qui, eux, font appel à ta bibliothèque.

Citation:

Merci Obsidian.

À ton service.
04/09/2011, 19h57
TomTom68

Je pratique déjà ainsi pour les unit tests et les stress tests, mais je cherche à fiabiliser mon développement et je reste ouvert aux erreurs en codant directement dans la lib avec les soucis que j'ai évoqué ('extern' non déclarés, fonctions non appelées, ...).
Pour ce qui ne fera par partie des fonctions mises à disposition par la lib, mais qui seront à son usage privé (d'ailleurs, en passant, comment garantir qu'elles vont n'être que ça et pas utilisables de l'extérieur), il faut bien que j'arrive à tester sans devoir compiler tester à chaque ligne pour ne pas me faire à nouveau piéger.
Passer par un exécutable regroupant mes structures propres, headers et sources code, me paraissait acceptable. Ca n'est visiblement pas ton avis. Peut-être peux-tu m'expliquer pourquoi et comment m'y prendre si je dois tester en direct dans la lib et ne pas m'auto-piéger par mes erreurs récurrentes ?

Merci de prendre le temps de répondre à chacune de mes questions, j'apprécie grandement.
04/09/2011, 20h12
Obsidian

Citation:

Envoyé par TomTom68

Pour ce qui ne fera par partie des fonctions mises à disposition par la lib, mais qui seront à son usage privé (d'ailleurs, en passant, comment garantir qu'elles vont n'être que ça et pas utilisables de l'extérieur),

Pour cela, il faut déclarer ces fonctions « static » (ce qui n'a pas la même signification que pour les variables). Dans ce cas, le symbole correspondant à la fonction ne sera pas exporté au delà du fichier source correspondant.
05/09/2011, 19h52
TomTom68
Bonsoir,

Donc, j'ai tenté les fonctions 'static' ...
Ca fonctionne bien pour celles qui sont internes à un source code et pas déclarées dans un header (normal), mais je ne vois pas quoi faire pour les fonctions qui sont déclarées dans un header pour des principes structurels à mon codage et néanmoins spécifiques et donc privées.

J'ai modifié les options de compilation ainsi :
Code:

1 2 3 CC = /usr/local/cross/gcc-3.3.4_glibc-2.3.2/arm-linux/bin/gcc CFLAGS = -std=c99 -W -Wall -O2 -fPIC -pedantic -finline-functions -Os LDFLAGS = -ldl -fvisibility=hidden -shared -lm
Mais je ne vois pas les bénéfices via objdump -t tout est toujours visible.

J'ai bien vu ça mais les scripts VERSION command sont des choses totalement nouvelles pour moi :
http://www.cims.nyu.edu/cgi-comment/...info%29VERSION

Comme je suis plus que débutant sur les makefile, une aide serait la bienvenue.
Merci.

EDIT : VERSION Command était LA solution, merci quand même.
06/09/2011, 11h35
matafan

Il faut soit que tu exportes explicitement les fonctions que tu veux exporter, soit que tu exclues explicitement les fonctions que tu ne veux pas exporter. Si tu n'exportes aucune fonction, alors par défaut le linker exporte tout, comme indiqué dans le man de ld pour --export-all-symbols.