On Fri, 27 May 2016, Alexey Tourbin wrote: > 2016-05-27 11:18 GMT+03:00 Ivan Zakharyaschev : >> Я-то не знаю, какой в каких спеках оно может иметь смысл, поэтому начал это >> обсуждение. (Хотел выкатить сразу большой список примеров, но пока так.) > > Смысл 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