PCRE2 10.37

Кстати, ребят, почему не собирается?

  CCLD libpcre2-8.la
  CCLD libpcre2-16.la
  CCLD pcre2grep
./.libs/libpcre2-8.so: undefined reference to `secure_getenv'
collect2: ld returned 1 exit status
make[1]: *** [pcre2grep] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/usr/src/packages/BUILD/pcre2-10.36'
make: *** [all] Error 2

У меня Glibc 2.11. Автор библиотеки говорит, что а). Вызов появился в Glibc 2.17 б). В программе нет этого вызова. И вообще попросил меня проверить файл src/config.h на предмет этого кода:

/* Define to 1 if you have the `secure_getenv' function. */                  
#define HAVE_SECURE_GETENV 1  

У меня так:

/* Define to 1 if you have the `secure_getenv' function. */

/* #undef HAVE_SECURE_GETENV */

Автор сказал, что src/config.h генерируется при помощи ./configure, который сам определяет, есть ли в моём Glibc этот вызов, или нет. Я попробовал компилировать как под GCC 4.3, так и под GCC 10, результат один. Автор говорит, что не может помочь, так как у него Arch и GCC 10, и проблема не воспроизводится.

Исправлено два бага, связанные с очень большими числами

А в чём заключались баги?

Кстати, ребят, почему не собирается?

Потому что ты всё никак не закопаешь стюардессу.

Автор говорит, что не может помочь, так как у него Arch и GCC 10

Ну ты понял.

Автор говорит, что не может помочь, так как у него Arch и GCC 10, и проблема не воспроизводится.

Нормально так.

Ну смотри, технических проблем, мешающих запуску, нет. Таких как зависимость от слишком нового ядра, Glibc, GCC, тулкита и т.д. Программа по-идее должна собираться и работать в том числе и на старых системах (и работает). Однако в версию 10.36 проникла регрессия, с которой я и пытаюсь разобраться. Пока сижу на 10.35 и ищу причину ошибки.

>> Автор говорит, что не может помочь, так как у него Arch и GCC 10, и проблема не воспроизводится.
> Нормально так.

Может это и не автор (или автор предыдущей реализации pcre). На странице проекта указаны адреса мейл-листов, баг-трекера, и e-mail автора Philip Hazel. Я решил, что написать емейл - самый быстрый способ, и написал.
Upd:

I'm afraid I am unable to help. I'm not familiar with different flavours of Linux - I run Arch Linux with, currently, gcc 10.2.0-6. Nobody else has ever posted anything like this issue. My only suggestion is that you comment out all the calls to getenv() in pcre2grep and see if that fixes the problem. It will, of course, reduce the functionality.

С Опеннета:

Например, выражение «/\214748364/» приводило к переполнению вместо обработки как восьмеричное число «\214» с идущими следом символами «748364».

Кстати, ребят, почему не собирается?

у вас линукс.

самый быстрый способ исправить баг - описать в трекере шаги как повторить. вангану, что при сборке не выставлен -D_GNU_SOURCE

p.s. >pattern matching

это называется regular expressions. pcre - perl-compatible regular expressions.

> самый быстрый способ исправить баг - описать в трекере шаги как повторить. вангану, что при сборке не выставлен -D_GNU_SOURCE

Спасибо за наводку. Пожалуй, так и сделаю. Просто не хотелось регаться на их баг-трекере, вот и решил тут спросить, может кто знает.

> это называется regular expressions. pcre - perl-compatible regular expressions.

Вон оно чё. Буду знать теперь.

запостил новость, чтоб тебе помогли с твоим копролитом? каков хитрец

Попробуй сначала запустить autoreconf, а потом уже ./configure

Вероятно все макросы от слишком новой версии autoconf/automake.

Вот интересно, тебе деньги платят за запуск нового софта на артефактах мустьерской культуры? Потому что иначе вообще непонятно что и зачем вообще.

а glibc какой версии? скорее всего, действительно что-то с самой системой сборки. что-то уже нагенерено в исходниках, которые ты скачал.

autoreconf -fiv делал. Используется autoconf 2.69 и automake 1.16.3. Лог сборки.

Glibc 2.11. Может попробовать более старый automake? Например 1.15.
Кстати да, я же обновлял automake недавно с 1.15 до 1.16. И после этого сломалась сборка pcre2. Может последний и ни при чём...

Это билд-ферма.

почему не собирается?

У меня Glibc 2.11

шлимазл ты

должна

это free software, сына. тебе никто ничего не должен, это сразу крупно написано

Nobody else has ever posted anything like this issue

зина один такой во всём мире. увожаю

попробовал компилировать как под GCC 4.3

Зенитара в модеры, чтоб дурацкие новости про обновление либ некрофильным способом не писал.

нет, у тебя скорее CFLAGS могут конфликтовать. сбросить те, что сам экспортируешь на безопасный дефолт типа -O2.

В логе вот это:

make -j6 'CFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -fprofile-generate'

Вообще, просматривая лог, обнаружил это:

In file included from src/sljit/sljitLir.c:267,
                 from src/pcre2_jit_compile.c:79:
src/sljit/sljitProtExecAllocator.c: In function 'create_tempfile':
src/sljit/sljitProtExecAllocator.c:125: warning: implicit declaration of function 'secure_getenv'
src/sljit/sljitProtExecAllocator.c:125: warning: assignment makes pointer from integer without a cast

Хотя автор говорил, что вызова secure_getenv нет...

У меня Glibc 2.11

На помойку.

То есть, когда половину проприетарного ПО собирают под CentOS 6, то это норм и в порядке вещей. А стоит версии Glibc быть на одну версию ниже, чем в CentOS 6, так всё

проприетарного ПО

на винфак

Проприетарный софт по моему ощущению всё-таки компилируют под последний Ubuntu LTS, а не какой-то там центось.

Но ты стрелки не переводи, скажи зачем тебе это старье вообще?

-D_FORTIFY_SOURCE=2 убери, хлебушек

Билд-ферма.

Под старые CentOS и SUSE компилируют обычно драйвер NVIDIA (а также до недавнего времени AMDGPU-PRO), JRE, и до недавнего времени Флеш. Сборки Qt5 с оф. сайта, Unreal Engine 4, да много что ещё. Как правило, в качестве билд-фермы используют CentOS, часто мы даже об этом не задумываемся.

Тебе бы лучше программировать учиться.

Открыл файл. #if HAVE_SECURE_GETENV там нет, а это значит что скорее всего у тебя нет другого выхода кроме как патчить исходники или перестать маяться фигней.

Так значит есть явный вызов этой функции?

И что ты такого собираешь? Для чего? Какой цели ты хочешь добиться?

Открой исходный код и посмотри самостоятельно.

Что собираю? Всё понемногу. Эмуляторы, например собрал несколько форков dosbox. Эмуляторы, например PS2 и 3. Игры: ezQuake, TeeWorlds. Хочу собрать нативного Сталкера, чтобы его можно было запустить в том числе и на старых системах - каких-то зубодробительных зависимостей, препятствующих этому, я не увидел. Медиаплееры и редакторы, например QMMP, OpenShot, Audacity. Не «осилил» к сожалению Ardour, но пока в процессе. И так далее. Раньше я использовал CentOS 5 в качестве базовой системы, но так как в 2017 году кончилась поддержка, я с неё ушёл. Скоро и с CentOS 6 придётся уходить.

Чего хочу добиться? Максимальный охват поддерживаемых дистрибутивов Linux. Кстати CUDA Toolkit тоже собирают с Glibc 2.11.

>> Так значит есть явный вызов этой функции?
> Открой исходный код и посмотри самостоятельно.

Странно, автор говорил следующее:

I've checked the PCRE2 source - it doesn't actually refer to SECURE_GETENV. The fact that something appears in config.h is an artefact of the autotools (i.e. ./configure) process.

грепни исходники на предмет этой secure_getenv

может она где без ифдефа используется

Ну вот это и скинь автору. Или запатчи сам.

Ща напишу. Насчёт «запатчить сам», я не знаю что писать после #ifdef. Задевайнить переменную что ли? Отменить вызов функции? Вызвать незащищённый вариант функции?

Получается, что если я собираю с Glibc 2.11, а запускаю в Glibc 2.17, то secured_getenv не будет вызываться, потому что я отключил эту возможность при сборке. В этом случае, теряется сам смысл билд-фермы на старой системе (охватить возможность запуска программы как в старой, так и в новой версии системы).

А нельзя типа компромисс? Собрать с Glibc 2.11, а дальше программа, если видит, что я запускаю её с библиотекой Glibc 2.17 или более новой, вызывает функцию secured_getenv вместо обычной?

Смотря какое проприетарное ПО. Если Скайп или Стим, то возможно. А если Nuke или Maya, то под самую старую РХЕЛ из поддерживающихся.

ZenitharChampion+ alpha=хабрхабр

Добрая и светлая новость

У меня вызвал сомнения тег perl. От перла-то, насколько я помню, взят только синтаксис регулярок, а сама библиотека написана на си и предназначена для си и си-совместимых (при наличии биндингов) языков.

Тег «c» явно просится вместо малоинформативных «инструменты» и «разработка». Тег «perl» можно оставить, но явно во вторую после «c» очередь. Есть ещё тег «regexp», по нему явно библиотеку для регулярок будут искать чаще, чем по «инструменты».

да я вижу, что в логах. ты же добавляешь какие-то свои CFLAGS?

а вообще я пропустил, у тебя glibc 2.11? то есть без поддержки secure_getenv? тогда найди эту проверку в configure и исправь ее в скриптах autotools.

у меня на glibc 2.16 собралось нормально.

может она где без ифдефа используется

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

Скоро и с CentOS 6 придётся уходить.

это да:(

Чего хочу добиться? Максимальный охват поддерживаемых дистрибутивов Linux. Кстати CUDA Toolkit тоже собирают с Glibc 2.11.

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

Ah, that's in the JIT code - my apologies, I didn't do a proper search of that code, which was silly of me. I have forwarded your message to the JIT maintainer for his comment.
Regards,
Philip

Исправление на подходе. Спасибо всем, что давал советы.

Хотя автор говорил, что вызова secure_getenv нет…

так его и нет в явном виде. Оно опосредованно вылазит через функцию create_tempfile. Смотри что там.

Перво наперво я бы скинул -Wall потому что это не еррор, а варнинг, а у тебя стоит все варнинги интерпретировать как ошибки.

Интересно, можно ли сделать так, чтобы код использовал secured_getenv по возможности, если доступен? Например, если я соберу прогу с Glibc 2.11, а запускать буду с Glibc 2.17. Получается что вместо secured_getenv будет использоваться обычный getenv, потому что в сборочном окружении не было защищённого варианта.

Например когда я собирал tor со всё тем же glibc 2.11, вот что он пишет при запуске:

May 31 15:20:45.599 [notice] Tor 0.4.5.8 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.1k-fips, Zlib 1.2.7, Liblzma 5.2.2, Libzstd N/A and Glibc 2.17 as libc.

Он видит, что в системе Glibc 2.17, и возможно использует какие-то вызовы, которые доступны в этой версии Glibc.

Интересно, можно ли сделать так, чтобы код использовал secured_getenv по возможности, если доступен?

по идее, да. что то типа такого

void attribute((weak)) secured_getenv() { secured_getenv() }

void secured_getenv() { getenv(); }

Скорее всего дело в параметре для ./configure - --enable-jit-sealloc.

Если тебе ненужна поддержка SElinux на старом Glibc - убери этот параметр из rpms.

Получается, что если я собираю с Glibc 2.11, а запускаю в Glibc 2.17, то secured_getenv не будет вызываться, потому что я отключил эту возможность при сборке.

Разумеется.

В этом случае, теряется сам смысл билд-фермы на старой системе (охватить возможность запуска программы как в старой, так и в новой версии системы).

Почему? Запускаться на новых системах она будет. Новые фичи использовать не будет.

А нельзя типа компромисс? Собрать с Glibc 2.11, а дальше программа, если видит, что я запускаю её с библиотекой Glibc 2.17 или более новой, вызывает функцию secured_getenv вместо обычной?

Это нужно реализовывать руками в коде. Много геморроя, мало толку. Иногда бывает оправдано, обычно смысла нет.