либиконв и MacOS

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

У меня проблема с либиконв. Сначала он жаловался на неопределенные символы для архитектуры 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, но я не хочу этого делать, так как у меня есть много портов, зависящих от него.


gcc osx-lion iconv libiconv
person Javier Moreno    schedule 27.09.2012    source источник
comment
как в итоге решил?   -  person Moj    schedule 13.03.2013

Ответы (5)


arrow_upward
7
arrow_downward

Я решил это:

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

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

person Erik Kaplun    schedule 07.12.2015

arrow_upward
3
arrow_downward

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

  1. В /usr/lib скопируйте libiconv.* как libiconv1.*
  2. Перейдите к [gcc-src]/gcc/Makefile.in
    измените LIBINTL = @LIBINTL@ на LIBINTL = @LIBINTL@ -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] ‹- должен быть абсолютный адрес. Я использую сделанные Macport gcc и g++. Возможно, использование gcc и g++ из системы тоже работает.
  4. make
  5. make install Двоичный файл будет в [gcc-src]/bin/
person user2368173    schedule 29.01.2014

arrow_upward
2
arrow_downward

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

person Quuxplusone    schedule 01.10.2013

arrow_upward
2
arrow_downward

Несмотря на то, что это старая тема, приведенное ниже решение может помочь кому-то, кто ищет исторические вопросы для помощи. Это простая однострочная команда, которая решит проблему, используя 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 's@\(iconv[^\(]*(\)@_lib\1@g' \
    $(grep -l -r 'iconv[^\(]*(' . 2>/dev/null)

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

person Joe Linoff    schedule 10.03.2018
comment
Спасибо, это сработало для меня при сборке GCC 6.3.0 stage 1 с использованием Xcode 10 в Мохаве. - person ztalbot; 25.10.2018
comment
Это сработало для компиляции git (и спасибо, это стало раздражать), но потребовалось небольшое изменение, чтобы заставить его работать: во-первых, явно укажите на ваш каталог iconv. ./configure --prefix=/usr/local/git-2.23.0 --with-iconv=/usr/local/iconv Затем измените исходный код, как указано выше, но @_lib\1g должен быть @lib\1g для меня ( без подчеркивания). Кроме того, приведенная выше команда зашла слишком далеко, поэтому верните эту строку в compat/precompose_utf8.c: верните libiconv_ibp cp' обратно в iconv_ibp. - person John Q; 26.08.2019
comment
На самом деле, меня так беспокоило изменение исходного кода git только для устранения ошибки iconv lib, что я углубился в это и решил полностью с изменениями Makefile, чтобы указать на правильную версию iconv lib. Я создал пост, чтобы объяснить, почему это происходит с iconv и как решить. - person John Q; 31.08.2019

arrow_upward
0
arrow_downward

Новый ответ на старый вопрос. Короткий ответ: в вашей системе есть несколько библиотек iconv. В stackoverflow есть масса связанных вопросов, которые на самом деле не отвечают на основную проблему, поэтому я создал ответ здесь, в котором подробно объясняется, что происходит и как решить проблему.

person John Q    schedule 31.08.2019