Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ __USE_STD_IOSTREAM ??

__USE_STD_IOSTREAM ??

2 réponses
Avatar
Erwann Thoraval
Bonjour,

je développe une petite application pour le traitement d'images. La
machine sur laquelle je bosse au boulot est en Tru64 et j'utilise cxx.
Jusque là, tout va bien. Mais lorsque j'essaie de lancer la compilation
chez moi (Linux 2.4.18) avec g++ (3.3.2), j'obtiens le message d'erreur
suivant dès la compilation du premier fichier :


Compilation de obj/CPP/background.o ...
g++: __USE_STD_IOSTREAM: No such file or directory
make: *** [obj/CPP/background.o] Error 1


le fichier background.h fait un #include <string.h> Voici le Makefile
:#--------- definition des repertoires du projet -----------
BASE_DIR= .
BIN = $(BASE_DIR)/bin
OBJ = $(BASE_DIR)/obj
OBJC++ = $(OBJ)/CPP
SRC = $(BASE_DIR)/src
INCLUDE = $(BASE_DIR)/include
DEPEND = $(BASE_DIR)/depend

#------ nom de l executable -----------
EXEC = $(BIN)/ray

# liste des repertoires contenant les .h
INCLUDES= -I$(INCLUDE) -I/usr/include -I/usr/local/include

# liste tous les fichiers .cc du projet
SRCSC++ = $(wildcard $(SRC)/*.cc)
# cree la liste des binaires C++ a partir de la liste des fichiers .cc
OBJSC++ = $(patsubst $(SRC)/%.cc,$(OBJC++)/%.o,$(SRCSC++))
# cree la liste de tous les binaires
OBJS = $(OBJSC++)
# liste les fichiers de dependances existants
DEPS = $(wildcard $(DEPEND)/*.d)

#Pour YSEULT
C++ = g++

C++FLAGS= $(INCLUDES) -ansi -Wall -Werror -O3 -DYYDEBUG=0__USE_STD_IOSTREAM C++DEPFLAG = -M

#----------------------------------------------------------------------
---- all: creationRepertoire $(EXEC)
@echo "Fin de la compilation"

creationRepertoire:
@echo "Creation des repertoires de travail"
@if [ ! -d $(DEPEND) ] ; then mkdir $(DEPEND) ;fi
@if [ ! -d $(OBJ) ] ; then mkdir $(OBJ) ;fi
@if [ ! -d $(OBJC++) ] ; then mkdir $(OBJC++) ;fi

$(EXEC): $(OBJS)
@echo "Linkage de $@ ..."
@$(C++) -std -o $@ $(OBJS) $(LIBS)

clean:
@echo "Effacement des repertoires de travail"
@rm -fr $(DEPEND)
@rm -fr $(OBJ)

clean_all: clean
@rm -f $(EXEC)

again: clean all

$(OBJC++)/%.o: $(SRC)/%.cc
@echo "Recherche des dependances de $@ ..."
@$(C++) $(INCLUDES) $(C++DEPFLAG) $< | sed 's/^.*\.o[:]*/\.\/obj\/CPP\/&/' > $(DEPEND)/$*.d
@echo "Compilation de $@ ..."
@$(C++) $(C++FLAGS) $< -o $@

#--------- fin du Makefile -----------

--
Erwann Thoraval
Signaler un problème avec ce contenu

2 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
Avatar
Jean-Marc Bourguet
Erwann Thoraval writes:

Compilation de obj/CPP/background.o ...
g++: __USE_STD_IOSTREAM: No such file or directory


Des problèmes avec des symboles commencant par __ dénotent souvent une
mauvaise installation ou une mauvaise utilisation.

# liste des repertoires contenant les .h
INCLUDES= -I$(INCLUDE) -I/usr/include -I/usr/local/include


Sous Unix, avec tous les compilateurs que je connais, indiquer
explicitement /usr/include comme répertoire où trouver des fichiers à
inclure est une bonne recette pour avoir des problèmes. gcc par
exemple (j'ai rencontré le problème aussi avec Sun CC) a tendance
tendance à utiliser des versions modifiées de ce qui s'y trouve et
spécifier explicitement /usr/include lui fait trouver les versions
originales. Je ne suis pas sûr que c'est la source des problèmes mais
c'est conforme avec les symptomes observés.

A+

--
Jean-Marc
FAQ de fclc++: 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
alexis.nikichine
Jean-Marc Bourguet wrote in message news:...
Erwann Thoraval writes:

Compilation de obj/CPP/background.o ...
g++: __USE_STD_IOSTREAM: No such file or directory


Des problèmes avec des symboles commencant par __ dénotent souvent une
mauvaise installation ou une mauvaise utilisation.


En l'occurence, ce message est vraiment bizarre, car
__USE_STD_IOSTREAM est une macro que doit définir l'utilisateur du
compilateur pour avoir des iostream "standards", contrairement aux
classes pré-standards (ca fait une inclusion conditionnelle d'un
header ou d'un autre, quelque part).

Si le projet doit compiler sur les deux OS, je suggérerais d'enlever
toute apparition du __USE_STD_IOSTREAM dans les sources, et le placer
dans les options de compilation, dans le makefile, si on est sur
Tru64, ou de l'enlever sur Linux.

Mais évidemment, de la à ce qu'il croit que __USE_STD_IOSTREAM est un
fichier et se mette à le chercher ...

# liste des repertoires contenant les .h
INCLUDES= -I$(INCLUDE) -I/usr/include -I/usr/local/include


Sous Unix, avec tous les compilateurs que je connais, indiquer
explicitement /usr/include comme répertoire où trouver des fichiers à
inclure est une bonne recette pour avoir des problèmes. gcc par
exemple (j'ai rencontré le problème aussi avec Sun CC) a tendance
tendance à utiliser des versions modifiées de ce qui s'y trouve et
spécifier explicitement /usr/include lui fait trouver les versions
originales. Je ne suis pas sûr que c'est la source des problèmes mais
c'est conforme avec les symptomes observés.


Il y aussi des compilateurs qui, voyant une
-I/chemin/invalide/ou/inexistant remettent à zéro la liste des chemins
d'inclusion, chemis systèmes compris.

Alexis