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

[Ivan Zakharyaschev]

On Fri, 27 May 2016, Alexey Tourbin wrote:

> 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.
>
> А что вы хотите исправить в пакетах?

Облегчить работу тем, кто будет массово собирать эти пакеты на других 
архитектурах (среди них некоторые 64-битные: aarch64, эльбрус)

Ну "облегчить" значит перейти из ситуации: несколько сотен пакетов не 
собралось (по каким-то глупым причинам, самая простая из которых 
несовпадение %_lib и lib) -- в ситуацию: несколько пакетов, требующих 
особого внимания по хитрым причинам (требуют написания 
архитектурно-зависимого кода), не собралось, а для остальных сработали те 
же приёмы, которые сработали для их сборки для x86_64 или i586.

> 1) Некоторые пакеты настолько беспомощны, что они не хотят свериться с
> препроцессором, а хотят, чтобы им явно сказали: "у нас 64 бита". Хотя,
> зачем? Использовали бы просто long и e.g. 1L в арифметике.
>
> 2) Некоторые пакеты поддерживают два режима на 64-битной платформе:
> неупакованный 64-битный и упакованный 32-битный, второй с некоторыми
> ограничениями на размер задачи и т.п. (CoinCsdp-6.1.1 можно было бы
> отнести к этому классу, если бы он не был слишком крив в других
> отношениях). Но как тогда его "исправить"? Он может работать в том или
> другом режиме.
>
> В общем, мне показалось, что вы хотите, чтобы rpm вам дал простой
> ответ, как исправить кучу кривых пакетов. Да никак их не исправить!
> Лучше их выкинуть, или хотя бы обновить до последней версии (а не
> заниматься пересборкой с увеличением релиза).


-- 
Best regards,
Ivan