[devel] ALT_2.24 (was: [#175881] p8 FAILED copy=SDL)

[devel] ALT_2.24 (was: [#175881] p8 FAILED copy=SDL)

[Alexey Tourbin]

On Sat, Jan 7, 2017 at 10:22 PM, Girar Builder awaiter robot
<girar-builder@altlinux.org> wrote:
> http://git.altlinux.org/tasks/175881/logs/events.1.1.log
>
> 2017-Jan-07 19:20:28 :: test-only task #175881 for p8 started by mike:
> #100 copy SDL from sisyphus
> 2017-Jan-07 19:20:30 :: copy from `sisyphus': SDL-1.2.14-alt7.src.rpm
> 2017-Jan-07 19:20:36 :: build check OK
> 2017-Jan-07 19:20:36 :: noarch check OK
> 2017-Jan-07 19:20:38 :: plan: src +1 -1 =17510, i586 +3 -3 =33884, x86_64 +3 -3 =33833
> 2017-Jan-07 19:20:38 :: version check OK
> 2017-Jan-07 19:21:54 :: generated apt indices
> 2017-Jan-07 19:21:54 :: created next repo
>         i586: NEW unmet dependencies detected:
> libSDL#1.2.14-alt7              libc.so.6(ALT_2.24)
>         x86_64: NEW unmet dependencies detected:
> libSDL#1.2.14-alt7              libc.so.6(ALT_2.24)(64bit)

Мужчины, это всё не очень хорошо. Своего интерфейса ALT_2.24 быть не должно.

В свое время генеральный конструктор озвучивал тезис: нас интересует
только запускаются ли программы из других дистрибутивов у нас;
запускаются ли наши программы в чужих дистрибутивах, нас не
интересует. Ну слушайте, эта асимметрия абсурдна по крайней мере в
этической плоскости. Это примерно как сказать, что если сдохла корова
у нас - то это нас интересует; а если у американцев - то слава богу,
не интересует!

$ readelf --wide --dyn-sym /lib64/libc.so.6 |grep ALT
   155: 00000000000f64e0    25 FUNC    GLOBAL DEFAULT   13
__strlcpy_chk@@ALT_2.24
   352: 00000000000f6500    25 FUNC    GLOBAL DEFAULT   13
__strlcat_chk@@ALT_2.24
  1671: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS ALT_2.24

С другой стороны, когда это всё висело на GLIBC_2.2, то это тоже было
не очень хорошо. Потому что это было обман.

У вас зависимость на интерфейс ALT_2.24 получат не отдельные редкие
пакеты, а массово все X-овые пакеты, потому что они кагбе BSD-шные и
там этот strlcpy везде пустил метастазы.

Когда я обдумывал эту тему где-то в 2011 году, я пришел к выводу, что
наименьшим из зол будет подключение strlcpy по линии -lc со стороны
статической библиотеки, кажется она называлась libc_nonshared.a.
По-моему, именно так тогда было сделано в дистрибутиве Owl. Возможен
также более или мене полный или частичный отказ от strlcpy в glibc
(можно, например, попытаться сделать символы недефолтными, чтобы они
все еще предоставлялись, но чтобы с ними уже нельзя было
слинковаться).

Re: [devel] ALT_2.24 (was: [#175881] p8 FAILED copy=SDL)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]

On Sun, Jan 08, 2017 at 02:48:04PM +0300, Alexey Tourbin wrote:
> On Sat, Jan 7, 2017 at 10:22 PM, Girar Builder awaiter robot wrote:
> > http://git.altlinux.org/tasks/175881/logs/events.1.1.log
> >
> > 2017-Jan-07 19:20:28 :: test-only task #175881 for p8 started by mike:
> > #100 copy SDL from sisyphus
> > 2017-Jan-07 19:20:30 :: copy from `sisyphus': SDL-1.2.14-alt7.src.rpm
> > 2017-Jan-07 19:20:36 :: build check OK
> > 2017-Jan-07 19:20:36 :: noarch check OK
> > 2017-Jan-07 19:20:38 :: plan: src +1 -1 =17510, i586 +3 -3 =33884, x86_64 +3 -3 =33833
> > 2017-Jan-07 19:20:38 :: version check OK
> > 2017-Jan-07 19:21:54 :: generated apt indices
> > 2017-Jan-07 19:21:54 :: created next repo
> >         i586: NEW unmet dependencies detected:
> > libSDL#1.2.14-alt7              libc.so.6(ALT_2.24)
> >         x86_64: NEW unmet dependencies detected:
> > libSDL#1.2.14-alt7              libc.so.6(ALT_2.24)(64bit)
> 
> Мужчины, это всё не очень хорошо. Своего интерфейса ALT_2.24 быть не должно.

Это лирика, интерфейс ALT_2.24 нужен, и он лучше, чем подселение
к GLIBC_2.2.5.

[...]
> У вас зависимость на интерфейс ALT_2.24 получат не отдельные редкие
> пакеты, а массово все X-овые пакеты, потому что они кагбе BSD-шные и
> там этот strlcpy везде пустил метастазы.
> 
> Когда я обдумывал эту тему где-то в 2011 году, я пришел к выводу, что
> наименьшим из зол будет подключение strlcpy по линии -lc со стороны
> статической библиотеки, кажется она называлась libc_nonshared.a.
> По-моему, именно так тогда было сделано в дистрибутиве Owl.

Да, и это было правильно, поскольку степень совместимости пакетов Owl
с пакетами соответствующего RHEL'а совершенно другого порядка.
Разные задачи -- разные решения.

> Возможен
> также более или мене полный или частичный отказ от strlcpy в glibc
> (можно, например, попытаться сделать символы недефолтными, чтобы они
> все еще предоставлялись, но чтобы с ними уже нельзя было
> слинковаться).

strlcpy с strlcat, которые подготовил Флориан для glibc
(см. https://sourceware.org/ml/libc-alpha/2016-05/msg00369.html)
это лучшая реализация strlcpy/strlcat из тех, что существуют.  Если софт
использует strlcpy/strlcat, то пусть уж использует лучшее из возможного.

Среди разработчиков glibc, к сожалению, нет консенсуса по этому вопросу,
поэтому вместо интерфейса GLIBC_2.24 новые символы попали в интерфейс
ALT_2.24.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] ALT_2.24 (was: [#175881] p8 FAILED copy=SDL)

[Alexey Tourbin]

2017-01-08 15:12 GMT+03:00 Dmitry V. Levin <ldv@altlinux.org>:
> On Sun, Jan 08, 2017 at 02:48:04PM +0300, Alexey Tourbin wrote:
>> On Sat, Jan 7, 2017 at 10:22 PM, Girar Builder awaiter robot wrote:
>> > http://git.altlinux.org/tasks/175881/logs/events.1.1.log
>> >
>> > 2017-Jan-07 19:20:28 :: test-only task #175881 for p8 started by mike:
>> > #100 copy SDL from sisyphus
>> > 2017-Jan-07 19:20:30 :: copy from `sisyphus': SDL-1.2.14-alt7.src.rpm
>> > 2017-Jan-07 19:20:36 :: build check OK
>> > 2017-Jan-07 19:20:36 :: noarch check OK
>> > 2017-Jan-07 19:20:38 :: plan: src +1 -1 =17510, i586 +3 -3 =33884, x86_64 +3 -3 =33833
>> > 2017-Jan-07 19:20:38 :: version check OK
>> > 2017-Jan-07 19:21:54 :: generated apt indices
>> > 2017-Jan-07 19:21:54 :: created next repo
>> >         i586: NEW unmet dependencies detected:
>> > libSDL#1.2.14-alt7              libc.so.6(ALT_2.24)
>> >         x86_64: NEW unmet dependencies detected:
>> > libSDL#1.2.14-alt7              libc.so.6(ALT_2.24)(64bit)
>>
>> Мужчины, это всё не очень хорошо. Своего интерфейса ALT_2.24 быть не должно.
>
> Это лирика, интерфейс ALT_2.24 нужен, и он лучше, чем подселение
> к GLIBC_2.2.5.

Это правда, что подселение к GLIBC_2.2 выглядело тоже плохо.

>> У вас зависимость на интерфейс ALT_2.24 получат не отдельные редкие
>> пакеты, а массово все X-овые пакеты, потому что они кагбе BSD-шные и
>> там этот strlcpy везде пустил метастазы.
>>
>> Когда я обдумывал эту тему где-то в 2011 году, я пришел к выводу, что
>> наименьшим из зол будет подключение strlcpy по линии -lc со стороны
>> статической библиотеки, кажется она называлась libc_nonshared.a.
>> По-моему, именно так тогда было сделано в дистрибутиве Owl.
>
> Да, и это было правильно, поскольку степень совместимости пакетов Owl
> с пакетами соответствующего RHEL'а совершенно другого порядка.
> Разные задачи -- разные решения.

А постановку задачи, нужна ли совместимость с другими дистрибутивами
или нет, ставит генеральный конструктор, силою своего ума. Взял с утра
закусил огурцом и сразу ясно, где тут задачи какого порядка.

> strlcpy с strlcat, которые подготовил Флориан для glibc
> (см. https://sourceware.org/ml/libc-alpha/2016-05/msg00369.html)
> это лучшая реализация strlcpy/strlcat из тех, что существуют.  Если софт
> использует strlcpy/strlcat, то пусть уж использует лучшее из возможного.
>
> Среди разработчиков glibc, к сожалению, нет консенсуса по этому вопросу,
> поэтому вместо интерфейса GLIBC_2.24 новые символы попали в интерфейс
> ALT_2.24.

А где там хорошее в коде, который Florian написал? Одно из других
возражений, которое я не успел написать, что нет кагбе
SSE2-реализации, которая бы оправдывала существование такой entry в
PLT. А если нету entry в PLT, то всё сводится к вызову memcpy, как у
Florian'а. А если всё сводится к вызову memcpy, тогда это не грех это
сделать static inline, или же добавлять glue code в libc_nonshared.a.

Хорошо в реализции Florian'а только то, что раньше это всё по одной
букве перебиралось, а теперь сведено к memcpy, который в типичном
случае делает 16 букв за раз; но это не заслуга Florian'а.

И кстати пишу всё это не голословно, недавно думал, как найти префикс
двух строк, в результате написал какой-то код для SSE2, может конечно
совсем детсадовский по меркам корифеев уровня H.J. Lu, но все-таки.
github.com/svpv/frenc/blob/master/lcp.h