From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 27 May 2016 21:24:24 +0300 (MSK) From: Ivan Zakharyaschev To: ALT Linux Team development discussions In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1807885841-660221951-1464373464=:1850" Subject: Re: [devel] other specs with "if 64"; was: Re: [AArch64] python3 spec fix X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 18:24:24 -0000 Archived-At: List-Archive: List-Post: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1807885841-660221951-1464373464=:1850 Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8BIT 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 --1807885841-660221951-1464373464=:1850--