EDIT2:
Итак, вот пример программы:
#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++ -std=c++0x -stdlib=libc++ -lc++ main.cc -o main
компилируется нормально.
2) g++-mp-4.8 -std=c++11 main.cc -o main
дает:
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
компилирует!
есть идеи что не так с настройкой?
==========
Может кто-нибудь помочь понять, что изменилось в Gcc / macports / os 10.9?
Раньше у меня был скрипт компиляции какой-то сторонней библиотеки, работающей в OS 10.8.
Недавно я обновился до нового osx (10.9) и gcc 4.7 из macports прекратил линковку. В частности у меня есть:
Undefined symbols for architecture x86_64:
"isspace(int)", referenced from:
Эта проблема очень похожа на упомянутую Вот за istype
,
Однако похоже isspace
не сидит в libgcc ++. dylib.
Есть идеи что попробовать?
EDIT1:
действительно, 4.8 исправил проблему с isspace
но всплыл еще один — toupper
:
Undefined symbols for architecture x86_64:
"toupper(int)", referenced from: ...
Что здесь происходит?!. Это связано с новым Xcode (5.0)?
Там есть патч в http://trac.macports.org/ticket/41033
Это решило мою проблему.
Вы просто должны исправить файл в /usr/include/sys/cdefs.h и заменить
#elif defined(__GNUC__) && defined(__GNUC_STDC_INLINE__)
от
#elif defined(__GNUC__) && defined(__GNUC_STDC_INLINE__) && !defined(__cplusplus)
Удачи.
Большинство из ctype.h
элементы объявляются как встроенные определения, поэтому они раскрываются во время компиляции. Когда вы компилируете без -std=c++11
, расширяется до:
extern inline int
toupper(int _c)
{
return (__toupper(_c));
}
Когда вы компилируете с -std=c++11
, расширяется до:
extern inline __attribute__((__gnu_inline__)) int
toupper(int _c)
{
return (__toupper(_c));
}
По какой-то причине g ++ предпочитает игнорировать совершенно хорошее определение, которое там представлено.
На основании комментария на этой недействительной ошибке, gcc выбирает не оптимизировать код и ищет определение в одной из связанных библиотек.
Обходной путь, кажется, должен компилироваться по крайней мере -O1
оптимизация, которая избегает проблемы, но это настоящая боль в заднице.
Теперь, когда мы посмотрим на различия в #defines между не-C ++ 11 и C ++ 11, мы увидим, что у нас есть дополнительный #define:
$ 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
и из-за куска кода в 10.9 SDK (usr/include/sys/cdefs.h
), всех тех __DARWIN_CTYPE_TOP_inline
в cytpe.h
быть превращенным в __header_inline
которые превращаются в extern __inline __attribute__((__gnu_inline__))
благодаря этому немного дополнительного кода:
#elif defined(__GNUC__) && defined(__GNUC_STDC_INLINE__)
# define __header_inline extern __inline __attribute__((__gnu_inline__))
Похоже, что заголовок Apple пытается сделать правильные вещи, но они не охватили все свои основы. Есть другая проблема, который упоминает похожую ошибку.
Я читал об ошибках компоновщика с Maverick в течение нескольких дней. Похоже, что проблема возникает с определенными инструментами перекрестного связывания, которые раньше были совместимы, но дольше.
Вы пытались заставить все инструменты использовать один тип clang ++ или llvm-g ++?