Bug 47144

(In reply to keremet from comment #0)
> Хотелось бы, чтобы был пакет libzstd-devel-static c библиотекой для
> статической линковки

А что будет с ней линковаться?

(Ответ для Gleb F-Malinovskiy на комментарий #1)
> А что будет с ней линковаться?

Библиотека нужна, чтобы была возможность скомпилировать форк Greenplum от Arenadata под Альт после вот этого коммита
https://github.com/arenadata/gpdb/commit/7185bf85ea8f4abdfdeb08d5a53180ea2f389728

(In reply to keremet from comment #2)
> (Ответ для Gleb F-Malinovskiy на комментарий #1)
> > А что будет с ней линковаться?
> 
> Библиотека нужна, чтобы была возможность скомпилировать форк Greenplum от
> Arenadata под Альт после вот этого коммита
> https://github.com/arenadata/gpdb/commit/
> 7185bf85ea8f4abdfdeb08d5a53180ea2f389728
Я думаю, что они неправы, когда называют эту фичу экспериментальной.  Она не экспериментальная, но её наличие зависит от того, как собран zstd.  В нашем случае libzstd собрана таким образом, что ZSTD_createDStream_advanced доступен в динамической библиотеке, её в этом случае и стоит использовать (т.е. просто сделать патч, который откатывает изменение про :libzstd.a).
Т.о., я не вижу смысла собирать статическую библиотеку.

Необходимость использовать статическую линковку описана в zstd.h:
Advanced experimental APIs should never be used with a dynamically-linked library. They are not "stable"; their definitions or signatures may change in the future. Only static linking is allowed.
https://git.altlinux.org/gears/z/zstd.git?p=zstd.git;a=blob;f=lib/zstd.h;h=e5c3f8b68b72e926b0720d7a2efec3f94792d92e;hb=69031eaa618e8271d78267f22bfa9c0d53a6d708#l101

и тут https://git.altlinux.org/gears/z/zstd.git?p=zstd.git;a=blob;f=lib/zstd.h;h=e5c3f8b68b72e926b0720d7a2efec3f94792d92e;hb=69031eaa618e8271d78267f22bfa9c0d53a6d708#l1161

Функция ZSTD_createDStream_advanced отмечена как ZSTDLIB_STATIC_API, поэтому необходимо собирать Greenplum со статической линковкой, иначе есть риск, что обновление пакета с libzstd.so поломает Greenplum.

Во многих других популярных дистрибутивах libzstd.a можно установить из пакетов (https://pkgs.org/search/?q=libzstd.a), и было бы очень здорово, если бы такая же возможность была доступна и в Альте. 

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

(In reply to keremet from comment #4)
> Необходимость использовать статическую линковку описана в zstd.h:
> Advanced experimental APIs should never be used with a dynamically-linked
> library. They are not "stable"; their definitions or signatures may change
> in the future. Only static linking is allowed.
> https://git.altlinux.org/gears/z/zstd.git?p=zstd.git;a=blob;f=lib/zstd.h;
> h=e5c3f8b68b72e926b0720d7a2efec3f94792d92e;
> hb=69031eaa618e8271d78267f22bfa9c0d53a6d708#l101
Хм.  Видимо, это значит, что динамическая библиотека вообще не должна эти символы экспортировать?

(Ответ для Gleb F-Malinovskiy на комментарий #5)
> Хм.  Видимо, это значит, что динамическая библиотека вообще не должна эти
> символы экспортировать?

Разработчики пишут "should", значит рекомендуют не делать динамическую линковку, но не запрещают. Если кому-то очень хочется, то пусть линкуют динамически, главное, чтобы понимали, что после обновления библиотеки что-то может перестать работать.

(In reply to keremet from comment #6)
> Разработчики пишут "should",

Там всё же "should never".

(Ответ для Gleb F-Malinovskiy на комментарий #5)
> Хм.  Видимо, это значит, что динамическая библиотека вообще не должна эти
> символы экспортировать?

Защита построена на том, что компиляция не будет выполнена без объявления макроса ZSTD_STATIC_LINKING_ONLY. Так программист как бы подтверждает, что готов на риск.

```
#include <zstd.h>

int main() {
	ZSTD_customMem c;
	ZSTD_createDStream_advanced(c);
	return 0;
}
```

При компиляции такой программки будут ошибки
```
$ gcc 1.c -lzstd
1.c: In function ‘main’:
1.c:6:2: error: unknown type name ‘ZSTD_customMem’
    6 |  ZSTD_customMem c;
      |  ^~~~~~~~~~~~~~
1.c:7:2: warning: implicit declaration of function ‘ZSTD_createDStream_advanced’; did you mean ‘ZSTD_createDStream’? [-Wimplicit-function-declaration]
    7 |  ZSTD_createDStream_advanced(c);
      |  ^~~~~~~~~~~~~~~~~~~~~~~~~~~
      |  ZSTD_createDStream

```

А если компилировать так ``` gcc 1.c -lzstd -DZSTD_STATIC_LINKING_ONLY ```, то все соберется успешно.

Да, это всё понятно.
Но я считаю, что для дистрибутива будет лучше, если помимо сборки статической библиотеки мы уберём такие символы из динамической библиотеки совсем.

(Ответ для Gleb F-Malinovskiy на комментарий #9)
> Но я считаю, что для дистрибутива будет лучше, если помимо сборки
> статической библиотеки мы уберём такие символы из динамической библиотеки
> совсем.

Если что-то убрать из динамической библиотеки, то есть риск, что тогда у кого-то что-то сломается раньше, чем апстрим zstd изменит API. Но так как наш Greenplum будет работать, сильно возражать не стану. Согласен на любой вариант

(In reply to keremet from comment #10)
> Если что-то убрать из динамической библиотеки, то есть риск, что тогда у
> кого-то что-то сломается раньше, чем апстрим zstd изменит API.
Если мы уберём символы, то мы сразу увидим, если ими кто-то пользовался по unmet-ам через set:versions.

> Но так как наш Greenplum будет работать, сильно возражать не стану. Согласен на любой вариант
Окей.  Возьмётесь сделать эти два изменения?
* добавление libzstd.a в виде пакета libzstd-devel-static (не забудьте добавить комментарий и написать в changelog, для какого пакета понадобился static-подпакет);
* убирание ZSTD_STATIC_LINKING_ONLY из динамической библиотеки.

(Ответ для Gleb F-Malinovskiy на комментарий #11)
> Окей.  Возьмётесь сделать эти два изменения?

Да

Кажется, апстрим никогда так не делал.

dictBuilder/cover.c:1122:21: warning: redeclaration of 'ZDICT_optimizeTrainFromBuffer_cover' with different visibility (old visibility preserved)
dictBuilder/cover.c:736:21: warning: redeclaration of 'ZDICT_trainFromBuffer_cover' with different visibility (old visibility preserved)
dictBuilder/fastcover.c:549:1: warning: redeclaration of 'ZDICT_trainFromBuffer_fastCover' with different visibility (old visibility preserved)
dictBuilder/fastcover.c:618:1: warning: redeclaration of 'ZDICT_optimizeTrainFromBuffer_fastCover' with different visibility (old visibility preserved)

Ну и pzstd не собирается с ожидаемой диагностикой:
ld: /usr/src/tmp/ccXXXXXX.ltrans1.ltrans.o:/usr/src/RPM/BUILD/zstd-1.5.5-alt1/contrib/pzstd/Options.h:64: undefined reference to `ZSTD_adjustCParams'
ld: pzstd: hidden symbol `ZSTD_getParams' isn't defined
ld: final link failed: bad value

Похоже, что они написали эти комментарии не для себя.

Создал задачу https://git.altlinux.org/tasks/327749/
В ней сборка завершилась с ошибкой на тестах. Ошибка воспроизводится стабильно. С точно такой же ошибкой сборка завершается и на текущем теге 1.5.5-alt1. Похоже, я что-то не так делаю, если пакет для 1.5.5-alt1 все-таки как-то собрался. Подскажите, пожалуйста, что можно сделать.

(In reply to Gleb F-Malinovskiy from comment #9)
> Да, это всё понятно.
> Но я считаю, что для дистрибутива будет лучше, если помимо сборки
> статической библиотеки мы уберём такие символы из динамической библиотеки
> совсем.

Из-за pzstd это превращается в сложную задачу, которую не факт, что кто-то захочет и сможет решить.

(In reply to Dmitry V. Levin from comment #15)
> Из-за pzstd это превращается в сложную задачу, которую не факт, что кто-то
> захочет и сможет решить.

Ну, попробовать стоило! :)

zstd-1.5.5-alt2 -> sisyphus:

 Wed Aug 23 2023 Dmitry V. Levin <ldv@altlinux> 1.5.5-alt2
 - Packaged static library (by Andrey Sokolov; closes: #47144).