Как скомпилять grep с pcre2?

а зачем греп, если есть перл? Он даже проще.

massimus ★★★
(29.10.22 18:13:13 MSK)

Ответ на: комментарий от massimus 29.10.22 18:13:13 MSK

я LFS собираю, grep всё-равно нужен. просто подумал, что мб с pcre2 получится

teod0r ★★★★★
(29.10.22 18:18:16 MSK) автор топика

Ссылка

Какая там версия grep?

Начиная с версии 3.8: src/pcresearch.c

27:#include <pcre2.h>

dataman ★★★★★
(29.10.22 18:32:49 MSK)

Ответ на: комментарий от dataman 29.10.22 18:32:49 MSK

а там 3.7 походу, из-за этого, попробую 3.8

teod0r ★★★★★
(29.10.22 18:39:53 MSK) автор топика

Ссылка

Ответ на: комментарий от dataman 29.10.22 18:32:49 MSK

да, в этом было дело. собралось, благодарен

teod0r ★★★★★
(29.10.22 19:05:11 MSK) автор топика

Ответ на: комментарий от teod0r 29.10.22 19:05:11 MSK

Рад помочь. :)

dataman ★★★★★
(29.10.22 19:21:38 MSK)

Ответ на: комментарий от dataman 29.10.22 19:21:38 MSK

подскажите пжлст ещё. собираю на финальной стадии LFS'а в чруте pkgutils (пакетный менеджер CRUX'а):

g++ -O2 -march=x86-64 -mmmx -msse -msse2 -mfpmath=sse -mlzcnt -mpopcnt -msahf -mno-sse4 -mno-shstk    -Wa,-mamd64,-O2,--strip-local-absolute -Wl,--no-omagic,--relax -pipe -Wall -fprofile-correction -fstack-clash-protection -fstack-protector-strong -fstack-protector-all  -D_GLIBCXX_ASSERTIONS -DNDEBUG -O2 -Wall -pedantic -D_GNU_SOURCE -DVERSION=\"5.40.7\" -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -MM main.cc pkgutil.cc pkgadd.cc pkgrm.cc pkginfo.cc > .depend
g++ -O2 -march=x86-64 -mmmx -msse -msse2 -mfpmath=sse -mlzcnt -mpopcnt -msahf -mno-sse4 -mno-shstk    -Wa,-mamd64,-O2,--strip-local-absolute -Wl,--no-omagic,--relax -pipe -Wall -fprofile-correction -fstack-clash-protection -fstack-protector-strong -fstack-protector-all  -D_GLIBCXX_ASSERTIONS -DNDEBUG -O2 -Wall -pedantic -D_GNU_SOURCE -DVERSION=\"5.40.7\" -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2  -c -o main.o main.cc
g++ -O2 -march=x86-64 -mmmx -msse -msse2 -mfpmath=sse -mlzcnt -mpopcnt -msahf -mno-sse4 -mno-shstk    -Wa,-mamd64,-O2,--strip-local-absolute -Wl,--no-omagic,--relax -pipe -Wall -fprofile-correction -fstack-clash-protection -fstack-protector-strong -fstack-protector-all  -D_GLIBCXX_ASSERTIONS -DNDEBUG -O2 -Wall -pedantic -D_GNU_SOURCE -DVERSION=\"5.40.7\" -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2  -c -o pkgutil.o pkgutil.cc
g++ -O2 -march=x86-64 -mmmx -msse -msse2 -mfpmath=sse -mlzcnt -mpopcnt -msahf -mno-sse4 -mno-shstk    -Wa,-mamd64,-O2,--strip-local-absolute -Wl,--no-omagic,--relax -pipe -Wall -fprofile-correction -fstack-clash-protection -fstack-protector-strong -fstack-protector-all  -D_GLIBCXX_ASSERTIONS -DNDEBUG -O2 -Wall -pedantic -D_GNU_SOURCE -DVERSION=\"5.40.7\" -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2  -c -o pkgadd.o pkgadd.cc
g++ -O2 -march=x86-64 -mmmx -msse -msse2 -mfpmath=sse -mlzcnt -mpopcnt -msahf -mno-sse4 -mno-shstk    -Wa,-mamd64,-O2,--strip-local-absolute -Wl,--no-omagic,--relax -pipe -Wall -fprofile-correction -fstack-clash-protection -fstack-protector-strong -fstack-protector-all  -D_GLIBCXX_ASSERTIONS -DNDEBUG -O2 -Wall -pedantic -D_GNU_SOURCE -DVERSION=\"5.40.7\" -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2  -c -o pkgrm.o pkgrm.cc
g++ -O2 -march=x86-64 -mmmx -msse -msse2 -mfpmath=sse -mlzcnt -mpopcnt -msahf -mno-sse4 -mno-shstk    -Wa,-mamd64,-O2,--strip-local-absolute -Wl,--no-omagic,--relax -pipe -Wall -fprofile-correction -fstack-clash-protection -fstack-protector-strong -fstack-protector-all  -D_GLIBCXX_ASSERTIONS -DNDEBUG -O2 -Wall -pedantic -D_GNU_SOURCE -DVERSION=\"5.40.7\" -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2  -c -o pkginfo.o pkginfo.cc
pkgutil.cc: In member function 'void pkgutil::pkg_install(const std::string&, const std::set<std::__cxx11::basic_string<char> >&, const std::set<std::__cxx11::basic_string<char> >&, bool) const':
pkgutil.cc:402:14: warning: ignoring return value of 'int chdir(const char*)' declared with attribute 'warn_unused_result' [-Wunused-result]
  402 |         chdir(root.c_str());
      |         ~~~~~^~~~~~~~~~~~~~
sed -e "s/#VERSION#/5.40.7/" pkgmk.in > pkgmk
sed -e "s/#VERSION#/5.40.7/" rejmerge.in > rejmerge
sed -e "s/#VERSION#/5.40.7/" pkgadd.8.in > pkgadd.8
sed -e "s/#VERSION#/5.40.7/" pkgrm.8.in > pkgrm.8
sed -e "s/#VERSION#/5.40.7/" pkginfo.8.in > pkginfo.8
sed -e "s/#VERSION#/5.40.7/" pkgmk.8.in > pkgmk.8
sed -e "s/#VERSION#/5.40.7/" rejmerge.8.in > rejmerge.8
sed -e "s/#VERSION#/5.40.7/" pkgmk.conf.5.in > pkgmk.conf.5
g++ main.o pkgutil.o pkgadd.o pkgrm.o pkginfo.o -o pkgadd -O2 -znoexecstack -znow -zseparate-code -zstart-stop-visibility=hidden -zrelro -static -larchive -lacl -llzma -lzstd -lbz2 -lz
/usr/bin/ld: cannot find -lacl: No such file or directory
/usr/bin/ld: cannot find -llzma: No such file or directory
/usr/bin/ld: cannot find -lzstd: No such file or directory
/usr/bin/ld: cannot find -lbz2: No such file or directory
/usr/bin/ld: cannot find -lz: No such file or directory
collect2: error: ld returned 1 exit status
make: *** [Makefile:46: pkgadd] Error 1

но все эти acl, lzma, zstd, bz2, zlib разумеется установлены. Что ему не хватает? какой-то переменной, где он их ищет? или чего? может,

undef ещё подскажет?

teod0r ★★★★★
(07.11.22 13:31:31 MSK) автор топика

Ответ на: комментарий от teod0r 07.11.22 13:31:31 MSK

все […] разумеется установлены

Куда?

Что ему не хватает?

Линкер не может их найти:

/usr/bin/ld: cannot find …

где он их ищет?

Обычно в /usr/lib и /usr/local/lib. Можно попробовать так: $ make CFLAGS=-Lпуть_к_установленным_либам

dataman ★★★★★
(07.11.22 14:17:57 MSK)

Ссылка

Ответ на: комментарий от teod0r 07.11.22 13:31:31 MSK

Не может найти указанные библиотеки. Значит хорошо бы посмотреть где их ищет gcc: gcc -print-search-dirs, убедиться, что они там есть, в том числе и ссылки типа libsome.so.

undef ★★★
(07.11.22 14:49:58 MSK)

Ответ на: комментарий от undef 07.11.22 14:49:58 MSK

в чруте:

# gcc -print-search-dirs
install: /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/
programs: =/usr/libexec/gcc/x86_64-pc-linux-gnu/12.2.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/12.2.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu/12.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/bin/
libraries: =/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/12.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../x86_64-pc-linux-gnu/12.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../lib/:/lib/x86_64-pc-linux-gnu/12.2.0/:/lib/../lib/:/usr/lib/x86_64-pc-linux-gnu/12.2.0/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../:/lib/:/usr/lib/

teod0r ★★★★★
(07.11.22 16:50:58 MSK) автор топика
Последнее исправление: teod0r 07.11.22 16:57:53 MSK (всего исправлений: 1)

Ответ на: комментарий от undef 07.11.22 14:49:58 MSK

убедиться, что они там есть, в том числе и ссылки типа libsome.so

# ll /FILES/toolchains/amd64/lib/libacl* /FILES/toolchains/amd64/usr/lib/libacl*
lrwxrwxrwx 1 root root    18 Nov  7 06:41 "/FILES/toolchains/amd64/lib/libacl.so.1" -> "libacl.so.1.1.2301"
-rwxr-xr-x 1 root root 46800 Nov  7 06:41 "/FILES/toolchains/amd64/lib/libacl.so.1.1.2301"
lrwxrwxrwx 1 root root    28 Nov  7 06:41 "/FILES/toolchains/amd64/usr/lib/libacl.so" -> "../../lib/libacl.so.1.1.2301"

teod0r ★★★★★
(07.11.22 16:53:34 MSK) автор топика
Последнее исправление: teod0r 07.11.22 16:54:07 MSK (всего исправлений: 1)

Ссылка

Ответ на: комментарий от teod0r 07.11.22 16:50:58 MSK

Точнее g++ -print-search-dir.

Еще бы поглядеть выхлоп /usr/bin/ld --verbose | grep SEARCH_DIR и, например, /usr/bin/ld -lacl --verbose

undef ★★★
(07.11.22 20:13:23 MSK)

Ответ на: комментарий от undef 07.11.22 20:13:23 MSK

# g++ -print-search-dirs
install: /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/
programs: =/usr/libexec/gcc/x86_64-pc-linux-gnu/12.2.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/12.2.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu/12.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/bin/
libraries: =/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/12.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../x86_64-pc-linux-gnu/12.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../lib/:/lib/x86_64-pc-linux-gnu/12.2.0/:/lib/../lib/:/usr/lib/x86_64-pc-linux-gnu/12.2.0/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../:/lib/:/usr/lib/

teod0r ★★★★★
(08.11.22 09:12:59 MSK) автор топика

Ссылка

Ответ на: комментарий от undef 07.11.22 20:13:23 MSK

# /usr/bin/ld --verbose | grep SEARCH_DIR
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64"); SEARCH_DIR("/usr/local/lib64"); SEARCH_DIR("/lib64"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");

teod0r ★★★★★
(08.11.22 09:14:12 MSK) автор топика

Ссылка

Ответ на: комментарий от undef 07.11.22 20:13:23 MSK

/usr/bin/ld -lacl --verbose

https://sebsauvage.net/paste/?e1869eeb1e914cc3#jCroS3dc59f05R kBLZDYTyzKCtNao...

teod0r ★★★★★
(08.11.22 09:18:28 MSK) автор топика

Ответ на: комментарий от teod0r 08.11.22 09:18:28 MSK

Таак, .so находит. libacl.a есть? Или попробуй -static из флагов убрать.

undef ★★★
(08.11.22 16:57:49 MSK)

Ответ на: комментарий от undef 08.11.22 16:57:49 MSK

попробуй -static из флагов убрать

а там в тарболе pkgutils нету ./configure скрипта, там в официальном дереве портов сразу make делается. можно конечно Makefile поправить...

libacl.a есть?

а вот таких файлов как раз нет. ни libacl.a, ни libz.a, ни ... оказывается, в книге LFS есть строки вида rm -fv /usr/lib/libz.a... а в дистре CRUX есть эти .a файлы!

лучше пойти путём мейнтейнеров дистрибутива и использовать .a файлы?

teod0r ★★★★★
(08.11.22 18:15:11 MSK) автор топика

Ответ на: комментарий от teod0r 08.11.22 18:15:11 MSK

а там в тарболе pkgutils нету ./configure скрипта, там в официальном дереве портов сразу make делается. можно конечно Makefile поправить

Таки да. Прибей -static - должно собраться.

В данном случае разрабы pkgutils явно задают статическую сборку, вероятно чтоб даже с самыми дикими проблемами с библиотеками ПМ работал. Типа, обновилась std c++ библиотека - ПМ не помер.

лучше пойти путём мейнтейнеров дистрибутива и использовать .a файлы?

Your distro - your rules.:) Хочешь сэкономить место - прибей *.a, кроме самых нужных. Или запили пакеты вида libacl, libacl-dev. Можно еще упороться за пару мегобайт и отдельно пилить libacl-dev-static.:)

undef ★★★
(08.11.22 18:49:05 MSK)

Ответ на: комментарий от undef 08.11.22 18:49:05 MSK

Вобщем, собрал тулчейн.
Начал в нём CRUX пересобирать. Дошло дело до glibc. glibc нормально собралось, и даже повторно пересобралось.
Но сборка glibc-32 выдаёт ошибку:

for symbol in __GI___pthread_disable_asynccancel __GI___pthread_enable_asynccancel __pthread_disable_asynccancel __pthread_enable_asynccancel calloc free malloc realloc  __stack_chk_fail __stack_chk_fail_local; do \
        echo ".globl $symbol"; \
        echo "$symbol:"; \
done | gcc -m32 -mstackrealign -o /w/t/src/build/elf/librtld.mapT.o -Werror=undef -Wa,--noexecstack  -c -x assembler -
gcc -m32 -mstackrealign -O2 -m32 -znoexecstack -znow -zseparate-code -zstart-stop-visibility=hidden -zrelro  -nostdlib -nostartfiles -r -o /w/t/src/build/elf/librtld.map.o /w/t/src/build/elf/librtld.mapT.o '-Wl,-(' /w/t/src/build/elf/dl-allobjs.os /w/t/src/build/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/w/t/src/build/elf/librtld.mapT
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc: No such file or directory
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:1296: /w/t/src/build/elf/librtld.map] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/w/t/src/glibc-2.36/elf'
make[1]: *** [Makefile:484: elf/subdir_lib] Error 2
make[1]: Leaving directory '/w/t/src/glibc-2.36'
make: *** [Makefile:9: all] Error 2

libgcc* в обычном CRUX:
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/32/libgcc.a
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/32/libgcc_eh.a
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/libgcc.a
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/libgcc_eh.a
/usr/lib/libgcc_s.so
/usr/lib/libgcc_s.so.1
/usr/lib32/libgcc_s.so
/usr/lib32/libgcc_s.so.1

В том что сейчас собираю:
/usr/lib/libgcc_s.so
/usr/lib/gcc/x86_64-lfs-linux-gnu/12.2.0/libgcc.a
/usr/lib/gcc/x86_64-lfs-linux-gnu/12.2.0/libgcc_eh.a
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/libgcc.a
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/libgcc_eh.a
/usr/lib/libgcc_s.so.1

Смущает строка /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/libgcc.a when searching for -lgcc в ошибке.
В LFS есть LFS_TGT=x86_64-lfs-linux-gnu, а в CRUX используется x86_64-pc-linux-gnu.
Мне надо пересобрать LFS с LFS_TGT=x86_64-pc-linux-gnu ?

teod0r ★★★★★
(28.11.22 12:32:11 MSK) автор топика

grep медленно работает в отличие от ripgrep’а

EXL ★★★★★
(28.11.22 12:38:51 MSK)

Ответ на: комментарий от undef 08.11.22 18:49:05 MSK

Ещё такой вопрос: здесь видны следущие опции компилятора:

gcc -m32 -mstackrealign -O2 -m32 -znoexecstack -znow -zseparate-code -zstart-stop-visibility=hidden -zrelro

Но это не все опции, которые я экспортировал. Здесь есть 'gcc -m32 -mstackrealign' — это было указано в порте — export CC="${CC:-gcc} -m32 -mstackrealign'; есть '-znoexecstack -znow -zseparate-code -zstart-stop-visibility=hidden -zrelro' — это мои экспортированные LDFLAGS.
Но здесь нет других моих CFLAGS! Это получается, что когда указывается CC, он игнорирует CFLAGS? Надо указывать CC="gcc ... $CFLAGS"???

teod0r ★★★★★
(28.11.22 12:46:00 MSK) автор топика
Последнее исправление: teod0r 28.11.22 12:47:40 MSK (всего исправлений: 1)

Ответ на: комментарий от EXL 28.11.22 12:38:51 MSK

Плюсую, после ripgrep пользоваться обычным невозможно - тормозит.

Ja-Ja-Hey-Ho ★★★★★
(28.11.22 12:49:22 MSK)

Ссылка

Ответ на: комментарий от teod0r 28.11.22 12:32:11 MSK

Если правильно помню, LFS не поддерживает мультилиб. Он отдельно прикручивался то ли в BLFS, то ли в хинтах. Сейчас gcc не может найти 32-битную libgcc.

undef ★★★
(28.11.22 13:19:01 MSK)

Ответ на: комментарий от teod0r 28.11.22 12:46:00 MSK

Эээ, а зачем флаги пихать в CC, когда для этого есть CFLAGS, LDFLAGS и пр.? Ну и, снова по памяти, сборочная система glibc могла фильтровать флаги, выпиливая негодные с ее точки зрения.

undef ★★★
(28.11.22 13:21:28 MSK)

Ссылка

Ответ на: комментарий от undef 28.11.22 13:19:01 MSK

Нашёл вот мультилибный LFS -> https://www.linuxfromscratch.org/~thomas/multilib/index.html
а LFS_TGT не надо менять?

teod0r ★★★★★
(29.11.22 09:12:42 MSK) автор топика
Последнее исправление: teod0r 29.11.22 09:13:14 MSK (всего исправлений: 1)

Ответ на: комментарий от teod0r 29.11.22 09:12:42 MSK

Если нет полного понимания, что просходит во время сборки, то лучше пересобрать LFS заново с мультилибом. В процессе сборки компилятор пару раз кросс-компилируется, хз какой там в итоге триплет получается.

Может быть достаточно будет на новой системе пересобрать binutils, gcc, glibc с поддержкой multilib и заменить ими существующие. Но могут быть нюансы.

undef ★★★
(29.11.22 14:12:58 MSK)

Ответ на: комментарий от undef 29.11.22 14:12:58 MSK

стал пересобирать с поддержкой мультилиб по этой инструкции -> https://www.linuxfromscratch.org/~thomas/multilib/index.html
возникли вопросы: почему там есть пакеты кроме glibc, которые собираются с 32-битами (bzip2, file, libcap, util-linux, ..., наверное каждый второй), в то время как в CRUX из 32-битного — тока glibc? вобщем, я стал собирать из 32-битного тока glibc.
а gcc , binutils — с флагом --enable-multilib. и я не собирал совсем x32. это не правильно?

при сборке file (глава 8.10.) возникает ошибка:

  CC       fmtcheck.lo
readelf.c: In function 'doshn':
readelf.c:145:33: warning: 'cap64.c_un.c_val' may be used uninitialized [-Wmaybe-uninitialized]
  145 | #define elf_getu64(swap, value) getu64(swap, value)
      |                                 ^~~~~~
readelf.c:1509:43: note: 'cap64' declared here
 1509 |                                 Elf64_Cap cap64;
      |                                           ^~~~~
readelf.c:144:33: warning: 'cap32.c_un.c_val' may be used uninitialized [-Wmaybe-uninitialized]
  144 | #define elf_getu32(swap, value) getu32(swap, value)
      |                                 ^~~~~~
readelf.c:1508:43: note: 'cap32' declared here
 1508 |                                 Elf32_Cap cap32;
      |                                           ^~~~~
readelf.c:144:33: warning: 'cap32.c_un.c_val' may be used uninitialized [-Wmaybe-uninitialized]
  144 | #define elf_getu32(swap, value) getu32(swap, value)
      |                                 ^~~~~~
readelf.c:1508:43: note: 'cap32' declared here
 1508 |                                 Elf32_Cap cap32;
      |                                           ^~~~~
readelf.c:145:33: warning: 'cap64.c_un.c_val' may be used uninitialized [-Wmaybe-uninitialized]
  145 | #define elf_getu64(swap, value) getu64(swap, value)
      |                                 ^~~~~~
readelf.c:1509:43: note: 'cap64' declared here
 1509 |                                 Elf64_Cap cap64;
      |                                           ^~~~~
readelf.c:144:33: warning: 'cap32.c_un.c_val' may be used uninitialized [-Wmaybe-uninitialized]
  144 | #define elf_getu32(swap, value) getu32(swap, value)
      |                                 ^~~~~~
readelf.c:1508:43: note: 'cap32' declared here
 1508 |                                 Elf32_Cap cap32;
      |                                           ^~~~~
readelf.c:144:33: warning: 'cap32.c_un.c_val' may be used uninitialized [-Wmaybe-uninitialized]
  144 | #define elf_getu32(swap, value) getu32(swap, value)
      |                                 ^~~~~~
readelf.c:1508:43: note: 'cap32' declared here
 1508 |                                 Elf32_Cap cap32;
      |                                           ^~~~~
readelf.c:145:33: warning: 'cap64.c_un.c_val' may be used uninitialized [-Wmaybe-uninitialized]
  145 | #define elf_getu64(swap, value) getu64(swap, value)
      |                                 ^~~~~~
readelf.c:1509:43: note: 'cap64' declared here
 1509 |                                 Elf64_Cap cap64;
      |                                           ^~~~~
readelf.c:145:33: warning: 'cap64.c_un.c_val' may be used uninitialized [-Wmaybe-uninitialized]
  145 | #define elf_getu64(swap, value) getu64(swap, value)
      |                                 ^~~~~~
readelf.c:1509:43: note: 'cap64' declared here
 1509 |                                 Elf64_Cap cap64;
      |                                           ^~~~~
  CCLD     libmagic.la
/usr/lib/gcc/x86_64-lfs-linux-gnu/12.2.0/../../../../x86_64-lfs-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-lfs-linux-gnu/12.2.0/../../../../lib/libz.a(zutil.o): warning: relocation against `z_errmsg' in read-only section `.text'
/usr/lib/gcc/x86_64-lfs-linux-gnu/12.2.0/../../../../x86_64-lfs-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-lfs-linux-gnu/12.2.0/../../../../lib/libz.a(zutil.o): relocation R_X86_64_PC32 against symbol `z_errmsg' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-lfs-linux-gnu/12.2.0/../../../../x86_64-lfs-linux-gnu/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:501: libmagic.la] Error 1
make[3]: Leaving directory '/build/file-5.43/src'
make[2]: *** [Makefile:382: all] Error 2
make[2]: Leaving directory '/build/file-5.43/src'
make[1]: *** [Makefile:464: all-recursive] Error 1
make[1]: Leaving directory '/build/file-5.43'
make: *** [Makefile:373: all] Error 2

пробовал собирать с -fPIC (CFLAGS), с --with-pic, с --disable-static, с --enable-shared, со всеми вместе — всё равно та же ошибка.
помоги пожалуйста разобраться почему ошибка. надо ли собирать 32-битное что-то кроме glibc? надо ли x32?

teod0r ★★★★★
(09.12.22 10:10:24 MSK) автор топика
Последнее исправление: teod0r 09.12.22 10:12:43 MSK (всего исправлений: 1)

Ответ на: комментарий от teod0r 09.12.22 10:10:24 MSK

почему там есть пакеты кроме glibc, которые собираются с 32-битами (bzip2, file, libcap, util-linux, …, наверное каждый второй), в то время как в CRUX из 32-битного — тока glibc? вобщем, я стал собирать из 32-битного тока glibc. а gcc , binutils — с флагом –enable-multilib. и я не собирал совсем x32. это не правильно?

На всякий случай. Когда будешь собирать с -m32 что-то сложнее HelloWorld, понадобятся 32-битные библиотеки. Если не собираешься использовать x32 (что скорее всего), можно и без него.

По ошибке сборки сложно сказать. Неясно какие флаги используются при сборке. Такое подозрение, что статическая libz.a собрана как неперемещаемая. Попробуй или пересобрать ее, или слинковаться с libz.so. Можно еще во флагах ./configure попробовать отключить zlib

undef ★★★
(11.12.22 02:07:16 MSK)

Ответ на: комментарий от undef 11.12.22 02:07:16 MSK

в итоге вот как решилось:
подсмотрел в CRUX'овом порте zlib и добавил после make install:

ln -sf "../../lib/libz.so.${ver[zlib]}" /usr/lib/libz.so
rm /lib/libz.so

Это что значит, что он не искал библиотеки в /lib? разве это нормально? как это глобально фиксится? LD_LIBRARY_PATH ? если да, где его указывать?

teod0r ★★★★★
(11.12.22 11:16:34 MSK) автор топика

Ответ на: комментарий от teod0r 11.12.22 11:16:34 MSK

Это нормально, не надо это фиксить. В /lib должны лежать либы, необходимые для загрузки системы (см. FHS). Средства разработки должны лежать в /usr/lib.

undef ★★★
(11.12.22 13:44:06 MSK)

Ссылка

Похожие темы