g ++ fallisce misteriosamente solo se un file .h si trova in una determinata directory

Question

Sto vivendo un problema estremamente strano in una nuova installazione di OSX 10.4.11 + Xcode 2.5. L'ho ridotto ad un caso di test minimale. Ecco test.cpp:

#include "macros.h" 

int main (void) 
{ 
    return 1; 
} 

Ed ecco macros.h:

#ifndef __JUST_TESTING__ 
#define __JUST_TESTING__ 

template<typename T> void swap (T& pT1, T& pT2) 
{ 
    T pTmp = pT1; 
    pT1 = pT2; 
    pT2 = pTmp; 
} 

#endif //__JUST_TESTING__ 

Questo compila e funziona bene se entrambi i file sono nella stessa directory. TUTTAVIA, se metto macros.h in/usr/include/gfc2 (è parte di una libreria personalizzata che uso io) e cambiare il # include nel test.cpp, la compilazione non riesce con questo errore:

/usr/include/gfc2/macros.h:4: error: template with C linkage 

ho ricercato quell'errore e la maggior parte dei commenti indicano una "C esterna penzolante", che non sembra affatto il caso.

Sono a perdita completa qui. È g ++ per qualche ragione supponendo che tutto in /usr/include/gfc2 sia C anche se è incluso da un file .cpp che non dice extern "C" da nessuna parte?

Qualche idea?

EDIT: Non compilare se uso il percorso completo nella #include, vale a dire #include "/usr/include/gfc2/macros.h"

EDIT2: Non è inclusa l'intestazione sbagliata. Ho verificato questo utilizzando cpp, g++ -E, e la ridenominazione macros.h a foobarmacros.h

Answer 1

G ++ potrebbe effettivamente essere supponendo che tutto in/usr/include è C. provare a compilare il codice con -E e studiare i marcatori di linea nell'output preprocessore:

g++ -E test.cpp | grep '^#' 

è probabile che tu vedi cose come

# 1 "/usr/include/gfc2/macros.h" 1 3 4 

il 4 è il preprocessore alludendo a G ++ che dovrebbe avvolgere tutto in extern "C", sulla supposizione che gli antichi file header della vostra piattaforma in/usr/include anteriori C++. Vedere Preprocessor Output nel manuale CPP.

In questi giorni G ++ ignora questo suggerimento, perché la maggior parte delle intestazioni C della piattaforma non è più antica. Vedere la macro target NO_IMPLICIT_EXTERN_C nel manuale GCC Internals. Ma può darsi che questa vecchia versione di Xcode abbia GCC configurato senza NO_IMPLICIT_EXTERN_C e quindi è ascoltando il suggerimento del preprocessore. (Questo è impostato quando GCC stesso è costruito - Non penso che ci sia un interruttore della riga di comando per sovrascriverlo.)

Potrebbe essere possibile aggirare il problema avvolgendo il contenuto del file di intestazione in extern "C++".

Answer 2

Beh, sembra davvero strano ...

Come si chiama XCode g ++? Non penso che g ++ decida spontaneamente che un file include ha il collegamento C solo perché si trova in una directory diversa. Hai provato a compilare il tuo progetto a mano? Prova "g ++ main.cpp -I/usr/include/gfc2 /". Se questo risolve il tuo problema, allora non è g ++. Forse XCode precompila le intestazioni?

Answer 3

non avete provato a cambiare il file test.cpp a tutti, ma invece quando si compila anche dire:

-I/usr/include/gfc2/ 

Answer 4

questo v'è un salto nel buio, ma è un altro file chiamato macros.h da qualche parte sotto /usr/include o nella tua installazione GCC? GCC ha una funzionalità per il wrapping delle intestazioni, chiamato #include_next, che potrebbe essere la causa del tuo problema.

Una cosa che puoi fare per disambiguare il tuo macros.h da qualsiasi altro macros.h nel percorso di inclusione è includerlo come gfc2/macros.h. In questo modo, il compilatore cercherà tutte le directory nel percorso di inclusione per una sottodirectory denominata gfc2 contenente un file denominato macros.h, riducendo la possibilità di una collisione. Inoltre, impedisce di dover aggiungere /usr/include/gfc2 al percorso di inclusione.

BTW, #include "file.h" cerca prima la directory corrente. Per saltare questo e andare dritto al percorso di inclusione, utilizzare #include <file.h>:

#include <stdio.h> 
#include <gfc2/macros.h> 

Un altro approccio è quello di scegliere un nome di file che è più probabile che sia unico, come gfc2macros.h.

Answer 5

Si può vedere dove g ++ è alla ricerca di include con il flag verbose:

g++ -v -o test test.cpp 

e questo basta eseguire il preprocessore e mostrare ciò che è effettivamente incluso nel file e compilato:

g++ -E test.cpp | less 

Se i file errati vengono inclusi (o l'intestazione viene incapsulata in un'altra, come suggerisce bk1e) sarete in grado di scoprire con quell'output.

Answer 6

Mi sono appena imbattuto in questo problema anche durante la compilazione di un progetto C++ che normalmente creiamo su 10.5 e 10.6 (Xcode 3.0+) su una macchina PPC 10.4 con Xcode 2.5 installato. Sembra che il preprocessore tratti qualsiasi cosa aggiunta al percorso di inclusione di gcc con "-isystem" come se fosse "extern C". La modifica di "-isystem" in "-I" ha risolto il problema.