Сообщения о том, что какая-то библиотека is not set-versioned, не мешают сборке. Нужно понять, откуда взялась зависимость на /usr/lib64/libc.so.6(GLIBC_2.14)(64bit), именно такие зависимости приводят к сообщениям, которые Вы видите. К сожалению, понять это, не имея возможности воспроизвести проблему локально, непросто.

Вы собираете Ваш проект? Из исходников? Можете поделиться? Вы не делаете что-нибудь странное с компоновщиком?

> ALT Linux p11 (официальный докер-образ)

Можете уточнить, какой именно? Хеш, теги?

Спасибо за пояснения, попробую разобраться, откуда берётся проблемная зависимость, я думал, что это последствия set-versioned.
Сборочный докер-образ у меня основан на свежем текущем alt:p11
RepoDigests: alt@sha256:301f3053b315587a1584d32f0d46dd9ab3f41120b5b0506e991fb43f1747fd98
в котором обычным образом установлены пакеты для сборки:
apt-get install -y glibc-devel meson zlib-devel и т.д.
Исходниками поделиться не могу, так как это закрытый код. Попробую пока сам.

У меня есть подозрение, что причина проблемных библиотек - в пакетах этих библиотек. Например, такая тестовая программа для проверки liblz4 (liblz4 - это одна из проблемных библиотек):

#include <stdio.h>
#include "lz4.h"

int main(int argc, char** argv)
{
    (void)argc; (void)argv;
    printf("Hello World ! LZ4 Library version = %d\n", LZ4_versionNumber());
    return 0;
}

на CentOS Stream 9 собирается успешно:

[root@14186f489e04 ~]# gcc -llz4 -o prog test.c
[root@14186f489e04 ~]# chmod +x prog 
[root@14186f489e04 ~]# ./prog 
Hello World ! LZ4 Library version = 10903

а на ALT Linux сборка выдаёт ошибку

[root@347e45b1a3f4 ~]# gcc -llz4 -o prog test.c
ld: /tmp/cc2muNOw.o: in function `main':
test.c:(.text+0x10): undefined reference to `LZ4_versionNumber'
collect2: error: ld returned 1 exit status

Библиотека и символ в действительности присутствуют:

[root@347e45b1a3f4 ~]# objdump -T /usr/lib64/liblz4.so.1 | grep LZ4_versionNumber
0000000000004c80 g    DF .text	0000000000000006  Base        LZ4_versionNumber

Также я заметил, что на CentOS Stream 9 (где нет ошибки установки) в зависимостях моего пакета эти библиотеки указаны в виде чистого soname:

[root@69acd03fbbc6 packages]# rpm --requires -qp ./mypackage-1.2.3-1.el9.x86_64.rpm | grep liblz4
liblz4.so.1()(64bit)

а на ALT Linux они указаны в виде soname с полным путём

[root@113afa5094e4 packages]# rpm --requires -qp ./mypackage-1.2.3-1.x86_64.rpm | grep liblz4
/usr/lib64/liblz4.so.1

и именно на зависимостях с полным путём возникает ошибка "not installable".

Не складывается ли это в какую-то единую картину? Что ещё можно сделать для локализации ошибки?

В качестве ALT Linux я использую текущий докер-образ alt:p11.

Для сравнения вот ещё выводы команд

на CentOS Stream 9, где установка успешна:
[root@2a5dbdc177ee /]# rpm -q --provides lz4-libs
liblz4.so.1()(64bit)
lz4-libs = 1.9.3-5.el9
lz4-libs(x86-64) = 1.9.3-5.el9

на ALT Linux p11
[root@347e45b1a3f4 ~]# rpm -qa | grep lz4
liblz4-1.9.4-alt1.x86_64
liblz4-devel-1.9.4-alt1.x86_64
[root@347e45b1a3f4 ~]# rpm -q --provides liblz4
liblz4.so.1()(64bit) = set:kdM5gNUbF3KIMt3ooTZHOp2fldcuDMknnKl5orJK759Af8VRAc7Z0Kn1SgSvsiLihMW1acRgjOHNzPqQPpQMfKoPdjoe4pZjCvX4sYK1ROZ4XJiap0NcuzRgiLh0iELAxziAxIvOiFM9MwOHBqNte1OYb2F19YqrnabgGpHW6FhdJZdu5413fH8r5
liblz4 = 1:1.9.4-alt1:sisyphus+309416.100.1.1

На CentOS provides сщвпадает с requires пакета, на ALT Linux - нет.

(In reply to pfe from comment #3)
> У меня есть подозрение, что причина проблемных библиотек - в пакетах этих
> библиотек. Например, такая тестовая программа для проверки liblz4 (liblz4 -
> это одна из проблемных библиотек):
> 
>   #include <stdio.h>
>   #include "lz4.h"
>   
>   int main(int argc, char** argv)
>   {
>       (void)argc; (void)argv;
>       printf("Hello World ! LZ4 Library version = %d\n", LZ4_versionNumber());
>       return 0;
>   }
> 
> на CentOS Stream 9 собирается успешно:
> 
>   [root@14186f489e04 ~]# gcc -llz4 -o prog test.c
>   [root@14186f489e04 ~]# chmod +x prog 
>   [root@14186f489e04 ~]# ./prog 
>   Hello World ! LZ4 Library version = 10903
> 
> а на ALT Linux сборка выдаёт ошибку
> 
>   [root@347e45b1a3f4 ~]# gcc -llz4 -o prog test.c
>   ld: /tmp/cc2muNOw.o: in function `main':
>   test.c:(.text+0x10): undefined reference to `LZ4_versionNumber'
>   collect2: error: ld returned 1 exit status
> 
> Библиотека и символ в действительности присутствуют:
> 
>   [root@347e45b1a3f4 ~]# objdump -T /usr/lib64/liblz4.so.1 | grep
>   LZ4_versionNumber
>   0000000000004c80 g    DF .text	0000000000000006  Base       
>   LZ4_versionNumber
А пакет liblz4-devel с симлинком /usr/lib64/liblz4.so, скорее всего, отсутствует.
  # apt-get install 'pkgconfig(liblz4)'
Вы ссылаетесь на CentOS; разве там не выделяют файлы для разработки в пакет "-devel"?

(Ответ для Arseny Maslennikov на комментарий #5)
> Вы ссылаетесь на CentOS; разве там не выделяют файлы для разработки в пакет
> "-devel"?
Да. Это было бы слишком, т.к. для 2-х soname уже не сделать 2-х devel-пакетов.
https://src.fedoraproject.org/rpms/lz4/blob/rawhide/f/lz4.spec

(In reply to pfe from comment #3)
> Также я заметил, что на CentOS Stream 9 (где нет ошибки установки) в
> зависимостях моего пакета эти библиотеки указаны в виде чистого soname:
> 
> [root@69acd03fbbc6 packages]# rpm --requires -qp
> ./mypackage-1.2.3-1.el9.x86_64.rpm | grep liblz4
> liblz4.so.1()(64bit)
> 
> а на ALT Linux они указаны в виде soname с полным путём
> 
> [root@113afa5094e4 packages]# rpm --requires -qp
> ./mypackage-1.2.3-1.x86_64.rpm | grep liblz4
> /usr/lib64/liblz4.so.1
> 
> и именно на зависимостях с полным путём возникает ошибка "not installable".
> 
> Не складывается ли это в какую-то единую картину? Что ещё можно сделать для
> локализации ошибки?
Предоставьте, пожалуйста, команды, которыми вы собираете пакет, а лучше — ещё и спек.

Ещё на всякий случай замечу, что далеко не все привычки упаковки под rh можно перенести на альт, и чем дальше, тем сильнее эти два мира расходятся. В частности, на сегодняшний день программа rpm и программа rpmbuild собираются из разных исходников и сопровождаются достаточно независимо, и первой из них собирать пакеты _не стоит_; `rpm -ba` даст не тот результат, что вы ожидаете, в отличие от rpmbuild -ba.

>  gcc -llz4 -o prog test.c

Во-первых, обратите внимание:

$ sudo apt-get update
[...]

$ sudo apt-get install liblz4-devel
[...]

$ gcc -llz4 -o prog test.c
ld: /tmp/.private/iv/ccLyrIwq.o: in function `main':
test.c:(.text+0x10): undefined reference to `LZ4_versionNumber'
collect2: error: ld returned 1 exit status

$ gcc -o prog test.c -llz4 && ./prog
Hello World ! LZ4 Library version = 10904

Наш gcc, как и многие другие, по умолчаню включает -Wl,--as-needed, поэтому библиотеки надо указывать после файлов, которые ими пользуются. Сборочный инструментарий (cmake, meson и т.п.) обычно так и делает.

Далее,

$ readelf -d prog | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [liblz4.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

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

Вот строка компоновщика одной из shared-библиотек:

[25/185] cc  -o subprojects/pb3-format-c/libpb3_encoder.so.1 subprojects/pb3-format-c/libpb3_encoder.so.1.p/pb3_cbor.c.o subprojects/pb3-format-c/libpb3_encoder.so.1.p/encoder.c.o subprojects/pb3-format-c/libpb3_encoder.so.1.p/decoder.c.o subprojects/pb3-format-c/libpb3_encoder.so.1.p/ft_hash.c.o subprojects/pb3-format-c/libpb3_encoder.so.1.p/compression.c.o subprojects/pb3-format-c/libpb3_encoder.so.1.p/shared.c.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,-soname,libpb3_encoder.so.1 -pipe -frecord-gcc-switches -Wall -g -O2 -Wl,--start-group subprojects/tinycbor/libtinycbor.a subprojects/spookyhash/libspookyhash.a -lpq /usr/lib64/libz.so -lzstd -llz4 -Wl,--end-group

Вот получившиеся зависимости этой библиотеки в заголовке:

[root@7563664ad248 ~]# readelf -d libpb3_encoder.so | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libzstd.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [liblz4.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
[root@7563664ad248 ~]# 

Но на этапе find-requires зависимые библиотеки, похоже, попадают в метаданные пакета с полными путями:

Processing files: libpb3-encoder-3.0.7~beta3~20250312g0a15594-1
Finding Provides (using /usr/lib/rpm/find-provides)
Executing: /bin/sh -e /tmp/rpm-tmp.iK8cKq
Finding Requires (using /usr/lib/rpm/find-requires)
Executing: /bin/sh -e /tmp/rpm-tmp.2SzQ4M
Provides: libpb3_encoder.so.1()(64bit) = set:kdqkmZjNkXms1fiYqLU92s0ZtKLdBmL5ud3jmUttcwtGqidw54YiZk1locpLZhxwpAaqopaQ516ZuvFzG8wvKGWTPqVXFfero7qeshcqK0CNfMQts32r6LF4AxCGiv8ZFNlZvf1da5GHANHlB2qZpNlZuEANGUzdbzL4MROd4
Requires: /usr/lib64/libc.so.6(GLIBC_2.14)(64bit), /usr/lib64/libc.so.6(GLIBC_2.2.5)(64bit), /usr/lib64/libc.so.6(GLIBC_2.3)(64bit), /usr/lib64/libc.so.6(GLIBC_2.3.4)(64bit), /usr/lib64/libc.so.6(GLIBC_2.33)(64bit), /usr/lib64/libc.so.6(GLIBC_2.38)(64bit), /usr/lib64/libc.so.6(GLIBC_2.4)(64bit), /usr/lib64/liblz4.so.1, /usr/lib64/libz.so.1(ZLIB_1.2.0)(64bit), /usr/lib64/libzstd.so.1, rtld(GNU_HASH)

Вот части спек-файла, относящиеся к сборке пакета этой библиотеки:

%build
%meson
%meson_build

%install
# ALT Linux has its own meson install macro. %distribution can be used to detect
# ALT Linux
%{?distribution: %__meson_install}%{!?distribution: %meson_install}

%clean
rm -rf $RPM_BUILD_ROOT

%files -n libpb3-encoder
%_libdir/libpb3_encoder*.so*

Пакеты собираются командой:
rpmbuild -bb --define="_lto_cflags %{nil}" --define="optflags_lto %{nil} спек-файл

Спасибо. Пока ничего особенного не видно, так что давайте попробуем копнуть глубже. Могу предложить два пути.

I. Вы можете добавить к rpmbuild ключ -vvv и приложить полученый лог сборки сюда? Что-то типа такого

rpmbuild -vvv -bb [...] 2>&1 | tee rpmbuild.log

Возможно, для понимания проблемы будет достаточно только того, что идёт после строки

Finding Requires (using /usr/lib/rpm/find-requires)

если что-то до этого Вы хотели бы скрыть. Может и сами почитать и это Вас на что-нибудь вдохновит, но там наверное будет очень много букв.

II. Нужно попробовать воспроизвести проблему на каком-то свободном пакете, которым Вы сможете нормально поделиться. Например, пересобрать пакет banner (https://packages.altlinux.org/en/sisyphus/srpms/banner/rpms/), и посмотреть, будут ли у него неправильные зависимости на /usr/lib64/libc.so.6. Или поискать что-нибудь маленькое собираемое meson'ом (сейчас мне ничего в голову не приходит).

Я понял, в чём непосредственная причина ошибки. Наши пакеты устанавливаются в /opt, поэтому в спек-файле я в самом начале переопределяю макросы:

%define _prefix /opt/mypackage/prog
%define _libdir %_prefix/lib

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

Прилагаю минималистический пример для воспроизведения (example.tgz), команды для воспроизведения в readme.txt.

Created attachment 17964 [details]
Код для воспроизведения ошибки

(In reply to pfe from comment #12)
> Я понял, в чём непосредственная причина ошибки. Наши пакеты устанавливаются
> в /opt, поэтому в спек-файле я в самом начале переопределяю макросы:
> 
> %define _prefix /opt/mypackage/prog
> %define _libdir %_prefix/lib
> 
> До этого я это не указывал, потому что считал, что это не влияет на сборку
> пакетов. Но причина точно в этом - с этими строчками ошибка возникает, без
> них - нет, всё собирается и устанавливается без ошибок.
> 
> Прилагаю минималистический пример для воспроизведения (example.tgz), команды
> для воспроизведения в readme.txt.

Вот вы сами накосячили, и почему-то вешаете багу на rpm-build.
Нельзя так делать.

Во-первых, я, действительно, сначала хотел посоветоваться и послал свой вопрос в рассылку community@lists.altlinux.org, но мне так никто и не ответил.

Во-вторых, поясните, в чём мой косяк? Макросы типа _libdir описывают пути для сборки и установки пакета и мне нужно, чтобы они были такими, какими я их задаю. На CentOS Stream, который является для меня эталоном RPM-based систем, никаких ошибок в этом случае не возникает.

(In reply to pfe from comment #15)
> Во-первых, я, действительно, сначала хотел посоветоваться и послал свой
> вопрос в рассылку community@lists.altlinux.org, но мне так никто и не
> ответил.
> 

community@ для таких вопросов не подходит.
Есть рассылка https://lists.altlinux.org/mailman/listinfo/devel-newbies

> Во-вторых, поясните, в чём мой косяк? Макросы типа _libdir описывают пути
> для сборки и установки пакета и мне нужно, чтобы они были такими, какими я
> их задаю. На CentOS Stream, который является для меня эталоном RPM-based
> систем, никаких ошибок в этом случае не возникает.

Это базовые макросы, их переопределять не надо.
Переопределите DESTDIR, если это Makefile.

(Ответ для pfe на комментарий #15)
> Во-вторых, поясните, в чём мой косяк? Макросы типа _libdir
Эти макросы используются всеми компонентами, участвующими в сборке, а не только вашим конечным пакетом. Переопределяя любые(не ваши) макросы будьте готовы, что что-то сломаете.

> Я понял, в чём непосредственная причина ошибки.

Ура)

(In reply to pfe from comment #15)
> Во-первых, я, действительно, сначала хотел посоветоваться и послал свой
> вопрос в рассылку community@lists.altlinux.org, но мне так никто и не
> ответил.

Не знаю, подходит ли для этого community@ (мне казалось что почему бы и нет?) но я не вижу Вашего письма ни у себя, ни в архивах. Возможно, Вы пропустили письмо от mailman, или не придали ему значения.

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

(In reply to Антон Мидюков from comment #16)
> Это базовые макросы, их переопределять не надо.
> Переопределите DESTDIR, если это Makefile.

Вы так ругаетесь на человека как будто это где-то документированно))

Но действительно, макросы %_prefix, %_libdir, %_bindir и подобные -- это не точки конфигурирования макросов. Они описывают систему, и именно в таком качестве используются как в пользовательских макросах (%configure, %makeinstall_std, %meson...) так и во внутренних частях rpm-build.

Например, после переопределения макроса %_libdir /usr/lib64, с точки зрения rpm, перестаёт быть стандартным путём поиска динамических библиотек. Отсюда и зависимости с полным путём.

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