non definito simbolo “toupper” in MacPorts GCC 4.7 OS-X Mavericks 10,9 C11

Question

EDIT2:

ecco un esempio del programma:

#include <stdio.h> 
#include <ctype.h> 
int main() 
{ 
    int i=0; 
    char str[]="Test String.\n"; 
    char c; 
    while (str[i]) 
    { 
    c=str[i]; 
    putchar (toupper(c)); 
    i++; 
    } 
    return 0; 
} 

1) clang:

clang++ -std=c++0x -stdlib=libc++ -lc++ main.cc -o main

compila bene.

2) g++-mp-4.8 -std=c++11 main.cc -o main dà:

Undefined symbols for architecture x86_64: 
    "toupper(int)", referenced from: 
     _main in ccWjHauc.o 
ld: symbol(s) not found for architecture x86_64 
collect2: error: ld returned 1 exit status 

3) g++-mp-4.8 main.cc -o main compilazioni!

qualsiasi idea cosa c'è di sbagliato nel setup?

==========

Qualcuno può aiutarmi a capire cosa è cambiato in GCC/macports/OS 10.9?

Avevo uno script di compilazione di alcune librerie di terze parti che funzionano su os 10.8. Recentemente ho aggiornato al nuovo osx (10.9) e gcc 4.7 da macports interrotto il collegamento. In particolare ho:

Undefined symbols for architecture x86_64: 
"isspace(int)", referenced from: 

Questo problema è molto simile a quello menzionato here per istype. Tuttavia sembra che isspace non sieda in libgcC++. Dylib.

Qualche idea cosa provare?

Edit1:

infatti, 4,8 risolto il problema con isspace, ma un altro a superficie - toupper:

Undefined symbols for architecture x86_64: 
    "toupper(int)", referenced from: ... 

Che cosa sta succedendo qui?!. È collegato al nuovo Xcode (5.0)?

Answer 1

C'è una patch in http://trac.macports.org/ticket/41033 Ha risolto il mio problema. Devi solo patchare il file in /usr/include/sys/cdefs.h e sostituire

#elif defined(__GNUC__) && defined(__GNUC_STDC_INLINE__) 

da

#elif defined(__GNUC__) && defined(__GNUC_STDC_INLINE__) && !defined(__cplusplus) 

Buona fortuna.

Answer 2

Ho letto gli errori di linker con Maverick per alcuni giorni. Il problema sembra emergere con determinati strumenti di cross linking che erano compatibili, ma più lunghi lo sono.

Hai provato a forzare tutti gli strumenti per utilizzare un tipo clang ++ o llvm-g ++?

Answer 3

La maggior parte degli articoli ctype.h sono dichiarati come definizioni in linea, quindi vengono espansi in fase di compilazione. Quando si compila senza -std=c++11, si espande per:

extern inline int 
toupper(int _c) 
{ 
     return (__toupper(_c)); 
} 

Quando si compila con -std=c++11, si espande per:

extern inline __attribute__((__gnu_inline__)) int 
toupper(int _c) 
{ 
     return (__toupper(_c)); 
} 

Per qualche ragione, g ++ è quindi scegliendo di ignorare la perfetta buona definizione che è presentato lì.

Sulla base del commento on this invalid bug, gcc sceglie di non ottimizzare il codice e di cercare la definizione in una delle librerie collegate.

Una soluzione sembra essere la compilazione con almeno l'ottimizzazione -O1, che evita il problema, ma è un vero rompicoglioni.

Ora, quando guardiamo le differenze nelle #defines tra non-C++ 11 e C++ 11, vediamo che abbiamo un # define in più:

$ touch x.cc 
$ g++-4.9 -dM -E x.cc | grep STD 
#define __STDC_HOSTED__ 1 
#define __STDC__ 1 
$ g++-4.9 -std=c++11 -dM -E x.cc | grep STD 
#define __STDC_HOSTED__ 1 
#define __GNUC_STDC_INLINE__ 1 
#define __STDC__ 1 

ed a causa di un pezzo di codice nel 10,9 SDK (usr/include/sys/cdefs.h), tutti coloro __DARWIN_CTYPE_TOP_inline in cytpe.h arrivare trasformato in __header_inline che vengono trasformati in extern __inline __attribute__((__gnu_inline__)) grazie a questo po 'di codice aggiuntivo:

#elif defined(__GNUC__) && defined(__GNUC_STDC_INLINE__) 
# define __header_inline   extern __inline __attribute__((__gnu_inline__)) 

sembra colpo di testa di apple sta cercando di fare il cosa giusta, ma non hanno coperto tutte le loro basi. C'è another issue, che menziona un bug simile.