Проблемы с сборкой gcc-4.3.4 в нестандартном месте - PullRequest
2 голосов
/ 14 января 2011

Мне нужно собрать gcc-4.3.4 в нестандартном месте (смонтирован NFS). Я настроил:

../gcc-4.3.4/configure --prefix={install dir} --with-gmp={install dir} --with-mpfr={install dir} --with-local-prefix={install dir} --disable-shared

Я побежал make -j1. Но я продолжаю получать:

checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile

В x86_64-unknown-linux-gnu/libgcc/config.log я вижу:

/home/panthdev/apps/gcc-4.3.4-compliant/compiler/objdir/./gcc/cc1: error while loading shared libraries: libmpfr.so.1: cannot open shared object file: No such file or directory

libmpfr.so.1 есть в {install dir}/lib. Также, если я установлю LD_LIBRARY_PATH на {install dir}/lib, то он найдет libmpfr.so.1, но config.log начнет жаловаться:

/tmp/cce9YhFK.s: Assembler messages:
/tmp/cce9YhFK.s:16: Error: bad register name `%rbp'
/tmp/cce9YhFK.s:18: Error: bad register name `%rsp'

Ответы [ 3 ]

2 голосов
/ 14 января 2011

Когда я читаю здесь , у вас есть 32-битные binutils, где gcc пытается выполнить 64-битную сборку. Убедитесь, что ваши binutils & gcc имеют такую ​​же конфигурацию.

0 голосов
/ 14 января 2011

В скрипте конфигурирования GCC 4.5.2 (у меня это доступно, но не 4.3.4), около строки 4500 (из строк 15.5K) есть строфа:

rm -f conftest.$ac_ext
EXEEXT=$ac_cv_exeext
ac_exeext=$EXEEXT
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for suffix of object files" >&5
$as_echo_n "checking for suffix of object files... " >&6; }
if test "${ac_cv_objext+set}" = set; then :
  $as_echo_n "(cached) " >&6
else
  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h.  */

int
main ()
{

  ;
  return 0;
}
_ACEOF
rm -f conftest.o conftest.obj
if { { ac_try="$ac_compile"
case "(($ac_try" in
  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
  *) ac_try_echo=$ac_try;;
esac
eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
$as_echo "$ac_try_echo"; } >&5
  (eval "$ac_compile") 2>&5
  ac_status=$?
  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
  test $ac_status = 0; }; then :
  for ac_file in conftest.o conftest.obj conftest.*; do
  test -f "$ac_file" || continue;
  case $ac_file in
    *.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.map | *.inf | *.dSYM ) ;;
    *) ac_cv_objext=`expr "$ac_file" : '.*\.\(.*\)'`
       break;;
  esac
done
else
  $as_echo "$as_me: failed program was:" >&5
sed 's/^/| /' conftest.$ac_ext >&5

{ { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
as_fn_error "cannot compute suffix of object files: cannot compile
See \`config.log' for more details." "$LINENO" 5; }
fi
rm -f conftest.$ac_cv_objext conftest.$ac_ext
fi

В основном, скрипт пытается скомпилировать 'conftest.c' и пытается найти расширение созданного объектного файла - и по какой-то причине ваш компилятор не создает conftest.o.

Это непервый тест, который он проводит на компиляторе, поэтому в вашей среде, кажется, происходит что-то довольно странное.

За последние годы я много раз собирал GCC - на Solaris и MacOS X - и явсегда использовал параметр --prefix.Это не проблема.Необходимы каталоги GMP, MPFR, MPC;единственный вариант, который вы использовали, с которым я не знаком, это --with-local-prefix.

Вы как-то указываете компилятор начальной загрузки?Попробуйте использовать текущую строку конфигурации с добавлением CC=/usr/bin/gcc или чего-то подобного, идентифицируя полностью работающий компилятор на вашем компьютере.Я не уверен, что это решит проблему, но есть что-то забавное в поведении компилятора или в расширениях объектных файлов, которые он создает.Я полагаю, у вас есть несколько ГБ свободного места на дисковой системе?Вам это понадобится.


Перелистывая страницу ' Установка GCC: конфигурация ', я нахожу:

--with-local-prefix=dirname

Укажите каталог установки для локальных включаемых файлов.По умолчанию /usr/local.Укажите эту опцию, если хотите, чтобы компилятор осуществлял поиск в каталоге dirname /include для локально установленных заголовочных файлов вместо /usr/local/include.

. Вы должны указывать --with-local-prefix, только если на вашем сайте естьдругое соглашение (не /usr/local) для размещения файлов, специфичных для сайта.

Значение по умолчанию для --with-local-prefix составляет /usr/local независимо от значения --prefix.Указание --prefix не влияет на то, в каком каталоге GCC выполняется поиск локальных заголовочных файлов.Это может показаться нелогичным, но на самом деле это логично.

Цель --prefix - указать, где установить GCC.Локальные заголовочные файлы в /usr/local/include - если вы поместили их в этот каталог - не являются частью GCC.Они являются частью других программ - возможно, многих других.(GCC устанавливает свои собственные заголовочные файлы в другой каталог, основанный на значении --prefix.)

И каталог включения local-prefix, и каталог включения GCC-prefix являются частью каталогов «system include» GCC,Хотя эти два каталога не являются фиксированными, их нужно искать в правильном порядке для правильной обработки директивы include_next.Каталог включения локального префикса ищется до того, как каталог включения префикса GCC.Еще одна особенность системных каталогов включения - то, что педальные предупреждения для заголовков в этих каталогах отключены.

Некоторые макросы autoconf добавляют параметры -I каталога -I в командную строку компилятора, чтобы обеспечить поиск в каталогах, содержащих заголовки установленных пакетов.,Если каталог является одним из системных включаемых каталогов GCC, GCC будет игнорировать эту опцию, чтобы системные каталоги продолжали обрабатываться в правильном порядке.Это может привести к тому, что порядок поиска будет отличаться от указанного, но поиск в каталоге будет продолжаться.

GCC автоматически ищет обычные библиотеки, используя GCC_EXEC_PREFIX.Таким образом, когда один и тот же префикс установки используется как для GCC, так и для пакетов, GCC автоматически выполняет поиск как заголовков, так и библиотек.Это обеспечивает конфигурацию, которая проста в использовании.GCC ведет себя подобно тому, как он установлен как системный компилятор в /usr.

Sites, которым необходимо установить несколько версий GCC, может не захотеть использовать вышеуказанную простую конфигурацию.Можно использовать опции --program-prefix, --program-суффикс и --program-transform-name для установки нескольких версий в один каталог, но может быть проще использовать разные префиксы и --with-опция local-prefix для указания расположения файлов сайта для каждой версии.Затем пользователям необходимо будет явно указать расположение локальных библиотек сайта (например, с помощью LIBRARY_PATH).

Одно и то же значение можно использовать как для --with-local-prefix, так и --prefix, если оно не /usr.Это можно использовать, чтобы избежать поиска по умолчанию /usr/local/include.

Не указывайте /usr как --with-local-prefix!Каталог, который вы используете для --with-local-prefix, не должен содержать никаких стандартных заголовочных файлов системы.Если бы они содержали их, некоторые программы были бы неправильно скомпилированы (включая GNU Emacs для определенных целей), потому что это переопределило бы и аннулировало исправления файла заголовка, сделанные скриптом fixinclude.

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

Вы уверены, что используете это правильно?Вы, вероятно, так как вам нужно искать, чтобы найти опцию - ../gcc-4.x.y/configure --help не упоминает опцию.

0 голосов
/ 14 января 2011

Возможно, вам следует попробовать --with-sysroot вместо --prefix.

...