[devel] other specs with "if 64"; was: Re: [AArch64] python3 spec fix

[Alexey Tourbin]

2016-05-27 11:18 GMT+03:00 Ivan Zakharyaschev <imz на altlinux.org>:
> Я-то не знаю, какой в каких спеках оно может иметь смысл, поэтому начал это
> обсуждение. (Хотел выкатить сразу большой список примеров, но пока так.)

Смысл 64-битной платформы. Имхо на 64-битность стоит смотреть не через
интерфейс large files, а через интерфейс mmap. Если можно очень
большой файл отобразить в память, то платформа 64-битная. То есть
играет роль адресное пространство и размер указателя. Но на всех
платформах имеем: sizeof(void*) == sizeof(long). Так что за неимением
лучшего надо проверять LONG_BIT.

А что вы хотите исправить в пакетах?

1) Некоторые пакеты настолько беспомощны, что они не хотят свериться с
препроцессором, а хотят, чтобы им явно сказали: "у нас 64 бита". Хотя,
зачем? Использовали бы просто long и e.g. 1L в арифметике.

2) Некоторые пакеты поддерживают два режима на 64-битной платформе:
неупакованный 64-битный и упакованный 32-битный, второй с некоторыми
ограничениями на размер задачи и т.п. (CoinCsdp-6.1.1 можно было бы
отнести к этому классу, если бы он не был слишком крив в других
отношениях). Но как тогда его "исправить"? Он может работать в том или
другом режиме.

В общем, мне показалось, что вы хотите, чтобы rpm вам дал простой
ответ, как исправить кучу кривых пакетов. Да никак их не исправить!
Лучше их выкинуть, или хотя бы обновить до последней версии (а не
заниматься пересборкой с увеличением релиза).

> Чтобы понять, как их можно было бы автоматически сделать более переносимыми,
> не написав глупостей, которые бы пошли вразрез с реальными возможностями
> (например: стали на двух архитектурах пытаться собирать одинаковым способом,
> а это вообще обычно не работает). Благодарю всех за уже полученные ответы и
> внимание к вопросу. Я пока на этапе доделки пакетов с проверкой %_libdir, а
> то, что останется, я продемонстрирую в продолжение этого обсужденияс
> вариантами переписывания.