From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <45081FA2.5020905@altlinux.com> Date: Wed, 13 Sep 2006 19:11:30 +0400 From: Anton Farygin User-Agent: Thunderbird 1.5.0.5 (X11/20060822) MIME-Version: 1.0 To: ALT Devel discussion list References: <4507FDBE.1090903@altlinux.com> <20060913125758.GG2722@basalt.office.altlinux.org> <45080270.5070200@altlinux.com> <20060913131758.GI2722@basalt.office.altlinux.org> <450805D6.2070902@altlinux.com> <20060913134054.GA8247@basalt.office.altlinux.org> <4508149D.2050008@altlinux.com> <20060913144456.GA9878@basalt.office.altlinux.org> In-Reply-To: <20060913144456.GA9878@basalt.office.altlinux.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] verify-elf X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.7 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2006 15:17:19 -0000 Archived-At: List-Archive: List-Post: Dmitry V. Levin wrote: > On Wed, Sep 13, 2006 at 06:24:29PM +0400, Anton Farygin wrote: >> Dmitry V. Levin wrote: >>> On Wed, Sep 13, 2006 at 05:21:26PM +0400, Anton Farygin wrote: >>> [...] >>>> кстати, запускал я его по весьма интересной причине - глючит verify-elf, >>>> если пакет собирать в хост системе и этот глюк не вылезает в hasher'е >>>> (что естественно). >>>> >>>> Глюк заключается в том, что verify-elf запускает ldd -r на бинарник, >>>> который слинкован с библиотекой из новой версии пакета. А в ней появился >>>> новый символ (без смены soname).. соответственно новый бинарник очень >>>> хочет этот новый символ, который старая библиотека не представляет.. ну >>>> и verify-elf на этом вылетает. Как бы его научить искать библиотеки >>>> сначала в %buildroot, а уже потом - в системе ? >>> Вообще-то я предпринимал определённые усилия по вычислению правильного >>> LD_LIBRARY_PATH, чтобы системные библиотеки проверялись в последнюю >>> очередь. Ты можешь добавить "set -x" в системный /usr/lib/rpm/verify-elf >>> и посмотреть, что там происходит на самом деле? >> конечно. >> >> Там выполняется вот такая команда: >> Возникает ощущение, что о втором аргументе ldd ничего не знает. > > "set -x" в /usr/lib/rpm/verify-elf больше не нужен, попробуй теперь > посмотреть отладочный вывод у /usr/lib/rpm/ldd. /lib64/ld-linux-x86-64.so.2 --library-path /home/rider/git.alt/curl/TMP/curl-buildroot/usr/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/usr/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/usr/X11R6/lib64 ./usr/bin/curl libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x00002b5081dc3000) libz.so.1 => /lib64/libz.so.1 (0x00002b5081f16000) libc.so.6 => /lib64/libc.so.6 (0x00002b508202b000) libidn.so.11 => /usr/lib64/libidn.so.11 (0x00002b5082251000) libssl.so.4 => /lib64/libssl.so.4 (0x00002b5082483000) libcrypto.so.4 => /lib64/libcrypto.so.4 (0x00002b50826ba000) libdl.so.2 => /lib64/libdl.so.2 (0x00002b50829fc000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) undefined symbol: curl_easy_escape (./usr/bin/curl) Т.е. - он то знает, а вот /lib64/ld-linux-x86-64.so.2 почему-то это всё игнорирует ;(