LINUX.ORG.RU

PCRE2 10.37

 , , , ,


0

1

Вышел релиз библиотеки PCRE2 10.37. PCRE2 это вторая версия оригинальной библиотеки PCRE с несовместимым API.

Библиотека PCRE2 это набор функций, которые реализуют регулярные выражения и сопоставление с образцом (pattern matching), используя синтаксис и семантику схожие с Perl 5.

Основные изменения:

  • Из библиотеки libpcre2-posix удалены символы POSIX-функций, такие как regcomp и т.д., так как они вызывали проблемы у некоторых приложений. Патч pcre2-symbol-clash.patch принят в апстрим. Также обновлена версия ABI этой библиотеки.
  • Исправлено гипотетическое разыменование нулевого указателя.
  • Исправлено два бага, связанные с очень большими числами, и теперь поведение идентично Perl.
  • Исправлено неправильное поведение при использовании \K.
  • Восстановлена оптимизация повторения символа в JIT.

>>> Подробности

★★★★★

Проверено: xaizek ()
Последнее исправление: Harald (всего исправлений: 4)

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

  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, и проблема не воспроизводится.

ZenitharChampion ★★★★★
() автор топика
Последнее исправление: ZenitharChampion (всего исправлений: 1)

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

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

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

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

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

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

Ну ты понял.

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

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

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

>> Автор говорит, что не может помочь, так как у него 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.

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

С Опеннета:

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

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

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

у вас линукс.

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

p.s. >pattern matching

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

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

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

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

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

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

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

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

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

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

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

Killy
()
Ответ на: комментарий от ZenitharChampion

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

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

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

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

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

ZenitharChampion ★★★★★
() автор топика
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

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

У меня Glibc 2.11

шлимазл ты

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

должна

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

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

Nobody else has ever posted anything like this issue

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

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

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

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

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

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

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

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

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 нет...

ZenitharChampion ★★★★★
() автор топика
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от a1batross

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

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

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

на винфак

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

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

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

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

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

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

Билд-ферма.

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

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

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

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

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

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

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

ZenitharChampion ★★★★★
() автор топика
Последнее исправление: ZenitharChampion (всего исправлений: 4)
Ответ на: комментарий от a1batross

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

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

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.

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

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

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

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

ZenitharChampion ★★★★★
() автор топика
Последнее исправление: ZenitharChampion (всего исправлений: 10)
Ответ на: комментарий от a1batross

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

meliafaro ★★★★★
()

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

perl5_guy ★★★★★
()

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

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

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 2)
Ответ на: комментарий от ZenitharChampion

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

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

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

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 2)
Ответ на: комментарий от Stil

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

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

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

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

это да:(

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

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

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

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

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

ZenitharChampion ★★★★★
() автор топика
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

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

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

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

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

Интересно, можно ли сделать так, чтобы код использовал 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.

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

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

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

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

void secured_getenv() { getenv(); }

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

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

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

Killy
()
Ответ на: комментарий от ZenitharChampion

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

Разумеется.

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

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

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

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

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