2012-09-27 4 views
13

Я пытаюсь скомпилировать GCC 4.5.1 в Mac OS X Lion.libiconv и MacOS

У меня проблема с libiconv. Сначала он жаловался на неопределенные символы для архитектуры x86_64, которые были: _iconv, _iconv_open и _iconv_close. Я узнал, что версия libiconv MacPorts переименовывает их в: _libiconv, _libiconv_open и _libiconv_close. Поэтому я связался с родным libiconv Mac OS в/usr/lib вместо библиотеки MacPorts в/opt/local/lib.

Undefined symbols for architecture x86_64: 
"_iconv", referenced from: 
    _convert_using_iconv in libcpp.a(charset.o) 
    __nl_find_msg in libintl.a(dcigettext.o) 
(maybe you meant: __cpp_destroy_iconv, _cpp_init_iconv) 
"_iconv_close", referenced from: 
    __cpp_destroy_iconv in libcpp.a(charset.o) 
    __cpp_convert_input in libcpp.a(charset.o) 
    __nl_free_domain_conv in libintl.a(loadmsgcat.o) 
"_iconv_open", referenced from: 
    _init_iconv_desc in libcpp.a(charset.o) 
    __nl_init_domain_conv in libintl.a(loadmsgcat.o) 

Однако, после того, как это делать, я попытался восстановить его с самого начала (чистки и все,), но затем он жаловался на другую точку о неопределенных символов, но на этот раз _libiconv, _libiconv_open и _libiconv_close.

Undefined symbols for architecture x86_64: 
    "_libiconv", referenced from: 
    _identifier_to_locale in libbackend.a(pretty-print.o) 
    "_libiconv_close", referenced from: 
    _identifier_to_locale in libbackend.a(pretty-print.o) 
    "_libiconv_open", referenced from: 
    _identifier_to_locale in libbackend.a(pretty-print.o) 

Есть ли какие-либо идеи о том, как я могу справиться с этим? Я нашел некоторые решения, удаляющие libiconv из MacPorts, но я не хочу этого делать, поскольку у меня много портов в зависимости от этого.

+4

как вы его окончательно решили? – Moj

ответ

2

Похоже, что ваш make clean на самом деле не удалил libbackend.a из каталога build; вы по-прежнему пытались установить связь со старой версией вашего кода, скомпилированной с MacPorts. В ручном режиме rm libbackend.a (или make distclean или make spotless или что-то, что действительно должно очистить все), вероятно, устранена проблема, не так ли?

3

Я решаю это, включив в себя два libiconv из обоих /usr/lib и /opt/local/lib. Это хакерский способ решить, если кто-то имеет лучшее решение, отправьте сообщение. Предположим, что [gcc-src] является исходным каталогом gcc. То, что я сделал это следующим образом:

  1. В /usr/lib, скопироватьlibiconv.* в libiconv1.*
  2. Перейти к [gcc-src]/gcc/Makefile.in
    изменение LIBINTL = @[email protected] в LIBINTL = @[email protected] -L/opt/local/lib -liconv -L/usr/lib -liconv1
  3. Настройка с помощью: CC=gcc-mp-4.7 CXX=g++-mp-4.7 ../gcc-4.7.2/configure --with-gmp=/opt/local --enable-languages=c,c++ --enable-checking=release —prefix=[gcc-src] < - должен быть абсолютный адрес , Я использую maccc-made gcc и g ++. Возможно, использование gcc и g ++ в работе системы тоже.
  4. make
  5. make install Двоичный будет [gcc-src]/bin/
3

Я решил ее:

$ sudo port -f deactivate libiconv 
$ ...build my project... 
$ sudo port activate libiconv 

Там, вероятно, лучший способ, но я не использую GCC напрямую, так что это помогает как временное обходное решение.

0

Даже если это старая нить, нижеприведенное решение может помочь кому-то найти исторические вопросы о помощи. Это простая однострочная команда, которая исправит проблему с помощью sed до , исправьте все ссылки на функции iconv.

$ tar xf gcc-6.4.0.tar.gz 
$ cd gcc=6.4.0 
$ # convert iconv(..)  --> _libiconv(..) 
$ # convert iconv_open(..) --> _libiconv_open(..) 
$ # convert iconv_close(..) --> _libiconv_close(..) 
$ LC_ALL=C time \ 
    sed -i.bak -e '[email protected]\(iconv[^\(]*(\)@_lib\[email protected]' \ 
    $(grep -l -r 'iconv[^\(]*(' . 2>/dev/null) 

Я использовал вышеупомянутое решение для этого проекта: https://github.com/jlinoff/gcc-6.4.0-boost-1.66.