Неопределенный символ «toupper» в MacPorts GCC 4.7 OS-X Mavericks 10.9 C11

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)?

8

Решение

Там есть патч в 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)

Удачи.

10

Другие решения

Большинство из 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 пытается сделать правильные вещи, но они не охватили все свои основы. Есть другая проблема, который упоминает похожую ошибку.

4

Я читал об ошибках компоновщика с Maverick в течение нескольких дней. Похоже, что проблема возникает с определенными инструментами перекрестного связывания, которые раньше были совместимы, но дольше.

Вы пытались заставить все инструменты использовать один тип clang ++ или llvm-g ++?

0
По вопросам рекламы [email protected]