[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