LINUX.ORG.RU

clang и библиотеки gcc

 , , ,


0

1

Задался я задачей перекомпилировать пару гнутых пакетов clang'ом, чтобы работало чуть по-шустрее. Перекомпилировал, и понял что хочу такое же но с чистой среды (/opt/local). Поработал, получилась вот такая чистая среда:

bash, version 4.2.37(2)-release
/bin/sh -> /opt/local/bin/bash
Binutils: LLVM version 3.1
bison (GNU Bison) 2.6.2
/usr/bin/yacc -> /opt/local/bin/bison
bzip2,  Version 1.0.6, 6-Sept-2010.
Coreutils:  8.19
diff (GNU diffutils) 3.2
find (GNU findutils) 4.4.2
GNU Awk 3.1.8
/usr/bin/awk -> /opt/local/bin/gawk
clang version 3.2 (trunk 163485)
version-check.sh: line 23: ldd: command not found
grep (GNU grep) 2.12
gzip 1.5
cat: /proc/version: No such file or directory
m4 (GNU M4) 1.4.16
GNU Make 3.82
GNU patch 2.7
Perl version='5.12.4';
GNU sed version 4.2.1
tar (GNU tar) 1.26
Texinfo: makeinfo (GNU texinfo) 4.13
xz (XZ Utils) 5.0.4
dummy.c:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
main(){}
^~~~
1 warning generated.
gcc compilation OK

(dummy.c компилируется clang'ом)

Так вот, проблема возникла такая: собрал в «чистой» среде binutils-2.22 (без ld и as), затем LLVM (получил llvm-ld, на который сделал симлинк ld и аналогично llvm-as) + clang. После сборки clang'а получил: clang, clang++, clang-tblgen, которыми успешно заменил gcc, g++, cc и c++. Далее ПРОБЛЕМА - мне нужни стандартние бібліотекі gcc, вот спісок:

* libgcc

* libgcov

* libgomp

* liblto_plugin (хз, может єта і не нужна)

* libmudflap (///)

* libquadmath

* libssp

* libstdc++

* libsupc++

Соответственно задумался где іх взять, логіка подсказала что прідется компіліровать gcc. Взялся за дело, но тогда gcc стал ругаться на libunwind, которий стал видавать туеву хучу ошібок. (лог не видаю ібо действовал неправільно і уже знаю) Поіскав в гугле, я нашел ісходнік libunwind, что мне впрочем не особо помогло. (тоже действовал неправільно, окавиаеца) Тогда ещґ погуглів наконец нашель что надо било компіліровать llvm-gcc. Сделав всґ по-інструкціі получіл следующій вихлоп:

gcc -c   -I/usr/include/ -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute  -Wno-error -mdynamic-no-pic -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../llvm-gcc-4.2-2.9.source/gcc -I../../llvm-gcc-4.2-2.9.source/gcc/build -I../../llvm-gcc-4.2-2.9.source/gcc/../include -I../../llvm-gcc-4.2-2.9.source/gcc/../libcpp/include -I/Users/homevehicle/GNU/sources/llvm-gcc-build/../gcc-4.7.1/mpfr/src -I../../llvm-gcc-4.2-2.9.source/gcc/../libdecnumber -I../libdecnumber -I/tools/include -DENABLE_LLVM -I/Users/homevehicle/GNU/tools/include  -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS   -o build/gengtype-lex.o gengtype-lex.c
clang: error: no such file or directory: 'gengtype-lex.c'
clang: error: no input files
make[2]: *** [build/gengtype-lex.o] Ошибка 1
make[2]: *** Ожидание завершения заданий...
../../llvm-gcc-4.2-2.9.source/gcc/llvm-linker-hack.cpp:39:10: fatal error: 
      'llvm/Target/TargetRegistry.h' file not found
#include "llvm/Target/TargetRegistry.h"
         ^
2 warnings and 1 error generated.
make[2]: *** [llvm-linker-hack.o] Ошибка 1
rm gcj-dbtool.pod gcjh.pod jcf-dump.pod grmiregistry.pod gjnih.pod jv-convert.pod grmic.pod gcov.pod gcc.pod gcj.pod jv-scan.pod gfdl.pod gij.pod cpp.pod fsf-funding.pod gpl.pod
make[2]: Выход из каталога `/Users/homevehicle/GNU/sources/llvm-gcc-build/gcc'
make[1]: *** [all-gcc] Ошибка 2
make[1]: Выход из каталога `/Users/homevehicle/GNU/sources/llvm-gcc-build'
make: *** [all] Ошибка 2

Буду копаться, что собственно не так, но, может быть, найдутся спецы, которые уже сталкивались с подобным и подскажут?

перекомпилировать пару гнутых пакетов clang'ом, чтобы работало чуть по-шустрее

/0

anonymous
()

В llvm в каждой новой версии внутренний API может быть нарушен, а раз llvm-gcc использует внутренние API, то компилировать его нужно ровно с той версией llvm, с которой его собирают разработчики. Или можно вручную подогнать llvm-gcc под изменения в API.

Библиотеки наверняка можно собирать по отдельности, да и в llvm-gcc не вижу необходимости. libstdc++ можно попробовать заменить на libc++ (но у неё ЕМНИП поддержка C++ 2011 гораздо хуже), libgomp и liblto_plugin не нужны

Использование clang не улучшит производительность.

quiet_readonly ★★★★
()
Ответ на: комментарий от quiet_readonly

/Библиотеки наверняка можно собирать по отдельности/ Вот про это мне интересно, я особо не нашел способа. Правда, кроме гугла нигде не искал. :D

/API может быть нарушен, а раз llvm-gcc использует внутренние API, то компилировать его нужно ровно с той версией llvm/ Как вариант - надо будет проверить, действительно у меня версии различаются (оказывается llvm-gcc идет к более старой llvm)

/Использование clang не улучшит производительность./ Под OSX улучшит, а мне именно туда и надо.

carthrbc
() автор топика
Ответ на: комментарий от carthrbc

Под OSX улучшит, а мне именно туда и надо.

GCC 4.7 работает под OSX, просто Apple им не пользуется.

quiet_readonly ★★★★
()

Задался я задачей перекомпилировать пару гнутых пакетов clang'ом, чтобы работало чуть по-шустрее

Откуда инфа?

Zorn
()
Ответ на: комментарий от carthrbc

Под OSX улучшит

Под osx процессор как-то иначе исполняет машкод?

anonymous
()
Ответ на: комментарий от io

Я ещё не собрал все нужные мне для работы пакеты. А компиляция если и стала шустрее, то незначительно (хз, не замерял с логарифмометром)

carthrbc
() автор топика
Ответ на: комментарий от Thero

В моем случае /tools/x86_64-apple-darwin-12.1.0/lib/llvm/dragonegg.so кстаті погуглів нашель у себя одну ошібку в CFLAGS))) Тем не менее, что странно, і с ней собралось

carthrbc
() автор топика
Ответ на: комментарий от Thero

Еще ошібка, но уже із-за копіпасти)) dylib же а не so

carthrbc
() автор топика
Ответ на: комментарий от carthrbc

ну да я оставил достаточно крошек чтобы понять про какой батон речь..

Thero ★★★★★
()

llvm-ld не является заменой ld или gold. Ни разу. Вообще.

Так же, замена gcc backend на llvm никак на скорость компиляции не повлияет. Clang существенно быстрее чем gcc, но только за счет frontend-а, а llvm тут не при делах.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.