From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 21 Feb 2023 17:33:33 +0300 From: "Dmitry V. Levin" To: devel@lists.altlinux.org Message-ID: <20230221143333.GA27015@altlinux.org> References: <20230220195209.64b208d2@rigel> <20230220174617.GB15329@altlinux.org> <20230220222326.16764731592a65ae4914d421@altlinux.org> <20230220202844.zcul74uzxlhlmxcu@titan.localdomain> <20230220235745.61137cf8@legato> <20230221002910.a2ed7b6d4f0f7e8ae132635f@altlinux.org> <20230221050521.yek4undy4vj42zqc@titan.localdomain> <20230221164658.accaa702d5af104e65c9e110@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230221164658.accaa702d5af104e65c9e110@altlinux.org> Subject: Re: [devel] libf2c-ng uses undefined symbol on i586 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: Tue, 21 Feb 2023 14:33:33 -0000 Archived-At: List-Archive: List-Post: On Tue, Feb 21, 2023 at 04:46:58PM +0300, Andrey Savchenko wrote: > On Tue, 21 Feb 2023 11:00:47 +0400 Gleb Fotengauer-Malinovskiy wrote: > > On Tue, Feb 21, 2023 at 09:05:21AM +0400, Ivan A. Melnikov wrote: > > > On Tue, Feb 21, 2023 at 12:29:10AM +0300, Andrey Savchenko wrote: > > > > On Mon, 20 Feb 2023 23:57:45 +0300 Paul Wolneykien wrote: > > > > > В Tue, 21 Feb 2023 00:28:44 +0400 Ivan A. Melnikov пишет: > > > > > > On Mon, Feb 20, 2023 at 10:23:26PM +0300, Andrey Savchenko wrote: > > > > > > > On Mon, 20 Feb 2023 20:46:17 +0300 Dmitry V. Levin wrote: > > > > > > > > On Mon, Feb 20, 2023 at 07:52:09PM +0300, Paul Wolneykien wrote: > > > > > > > > > В Mon, 20 Feb 2023 17:31:30 +0100, Kirill Maslinsky пишет: > > > > > > > > > > > > > > > > > > > > Думаю, что эти подпакеты просто должны перестать быть noarch. Они > > > > > > > > > > > больше не подходят для всех архитектур. > > > > > > > > > > > > > > > > > > > > Последовал Вашему совету, и результат вышел несколько неожиданный: > > > > > > > > > > > > > > > > > > > > i586: NEW bad_elf_symbols detected: > > > > > > > > > > libf2c-ng-20200916-alt1.i586.rpm /usr/lib/libf2c.so.0.0.0 U MAIN__ > > > > > > > > > > > > > > > > > > > > Это вообще связано со сборкой R, или это какой-то посторонний эффект? > > > > > > > > > > > > > > > > > > Насколько я помню, это сообщение переводится так: символ затребован > > > > > > > > > как external, но ни одним из пакетов в Сизифе не предоставляется. > > > > > > > > > > > > > > > > Другими словами, это ошибка в пакете libf2c-ng-20200916-alt1.i586.rpm > > > > > > > > > > > > > > Нет, это не ошибка в пакете libf2c-ng. Это не вполне корректная > > > > > > > работа системы проверки зависимостей сборочницы, которая делает > > > > > > > слишком строгие, но не всегда корректные предположения, потому что > > > > > > > некоторые символы могут генерироваться компилятором самостоятельно > > > > > > > в процессе компиляции кода. Это нетипичная, но вполне легитимная > > > > > > > операция. > > > > > > > > > > > > > > Во время адаптации f2c-ng для целей e2k я решил эту и иные проблемы. > > > > > > > Конкретно эта проблема заткнута функцией пустышкой в синтетической > > > > > > > библиотеке, единственный смысл которой в том, чтоб удовлетворить не > > > > > > > вполне корректную проверку сборочницы. > > > > > > > > > > > > Как я понял, функция MAIN__ предоставляется программами, полученными > > > > > > из исходников на фортране при помощи f2c-ng; если в репозитории > > > > > > не осталось ни одной программы, полученной таким образом, > > > > > > > > > > Тогда логичнее, наверное, сделать не библиотеку пустышку-заглушку, > > > > > а добавить в пакет f2c-ng демонстрационную программу, в которой будет > > > > > этот символ. > > > > > > > > Наличие символа в программе не исправит проблему, потому что при > > > > поиске зависимостей важны символы в библиотеках, а не исполняемых > > > > файлах. Поэтому нужна "демонстрационная" библиотека, что я и сделал. > > > > > > Мне казалось, что конкретно эта проверка не делает разделения > > > на библиотеки и исполняемые файлы, а просто собирает все > > > ELF'ы, которые shared, независимо от имени и пути. > > > > Верно. > > > > > > Решение на стороне сборочницы (в виде исключения для MAIN__), > > > > безусловно, правильнее [...] > > > > На самом деле, не правильнее. Гораздо лучше и проще было бы сделать > > этот символ __attribute__((weak)). > > Так этого символа в библиотеке совсем нет. А если добавить > заглушку даже weak, но я не уверен, что ничего не сломается, т.к. > MAIN__ обрабатывается сильно особым способом. Не сам символ MAIN__ сделать weak, а undefined reference на него в библиотеке. -- ldv