Беда компиляции современного GCC с античным glibc

Я пытаюсь заставить современный GCC компилироваться на Centos 6.4. Проблема в том, что Centos не имеет современного glibc, а GCC 4.8.x и 4.7.x продолжают выдавать мне следующую ошибку компиляции:

... -DL_gcov -c ../../.././libgcc/libgcov.c
In file included from /usr/include/features.h:385:0,
                 from /usr/include/stdio.h:28,
                 from ../../.././libgcc/../gcc/tsystem.h:88,
                 from ../../.././libgcc/libgcov.c:29:
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory

Проблема здесь заключается в gnu/stubs-32.h является частью современного glibc и Centos 6.4, кажется, не имеет его. Я пытался построить свой собственный glibc но как только он будет установлен и в моем местном LD_LIBRARY_PATH Я не могу запустить какие-либо другие программы, потому что все существующие исполняемые файлы в системе пытаются связать их, и они терпят неудачу.

Я хочу использовать новый компилятор, потому что он значительно лучше обрабатывает код C++ STL, и потому что оптимизатор в GCC 4.8 заставляет мой код работать в 1/2 раза быстрее, чем компилятор GCC 4.4.7, который поставляется с Centos.

Любые предложения о том, как это сделать?

Источник

3 ответа

Решение

Создайте компилятор gcc на вашем Centos и выберите только 64 бита.
Выдержка из документации:

Стандартная библиотека C и заголовки Для построения GCC стандартная библиотека C и заголовки должны присутствовать для всех целевых вариантов, для которых будут создаваться целевые библиотеки (а не только для варианта компилятора хоста C++). Это влияет на популярную платформу 'x86_64-unknown-linux-gnu' (среди прочих мультибиблиотечных целей), для которой 64-битные ('x86_64') и 32-битные ('i386') заголовки libc обычно упаковываются отдельно. Если вы делаете сборку собственного компилятора на "x86_64-unknown-linux-gnu", убедитесь, что у вас либо правильно установлен 32-битный пакет разработчика libc (точное имя пакета зависит от вашего дистрибутива), либо вы должны собрать GCC как 64-битный компилятор, конфигурируемый с опцией --disable-multilib. В противном случае вы можете столкнуться с ошибкой, такой как "фатальная ошибка: gnu/stubs-32.h: такого файла нет"

Источник

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

Мне нужно было сделать это только на CentOS 5, так что, возможно, вы сможете обойтись более высокими версиями программного обеспечения, чем я упоминаю.

Вам нужно будет построить GLIBC следующим образом:

CFLAGS='-march=i686 -O2' ../configure --prefix=/home/glibc215 \
  make -j 4 && make install

(Я использовал GLIBC 2.15, аналогичные команды должны работать с более новыми версиями)

После того, как оно будет построено, запустите приложение вручную, выполнив что-то вроде этого:

/home/glibc215/lib/ld-linux.so.2 --library-path /home/glibc215/lib/:. /bin/bash

Все будет еще сложнее из-за того, что вам нужна современная версия GCC. У меня нет для вас достойного решения, вам нужно будет поиграть с запуском в альтернативной версии glibc, чтобы ваш новый gcc правильно собирался.

Источник

Вы можете установить более новый glibc в ~/lib и установите GCC в ~/bin и связывание с новым glibc. Я бы посоветовал использовать это только для вашего приложения, которое работает на суперкомпьютере, и статически связывать все (включая libc), чтобы избежать большего беспорядка, чем вы должны будете сделать для этого.

Это не очень аккуратное / элегантное решение, но оно может просто сделать работу. Я делал нечто подобное несколько лет назад, когда копался в ld.so и не хотел портить всю систему:-)

Источник
Другие вопросы по тегам