[devel] q: _perl_vendor_check_dso problems

[devel] q: _perl_vendor_check_dso problems

[Vladimir Lettiev]

Не получается "стандартно" собрать модуль перла libapreq-1.33 ( 
http://httpd.apache.org/apreq/ )

на этапе проверки dso вылезает жуть вида:

...
+ gcc ldtest.c -lperl 
/home/crux/RPM/BUILD/libapreq-1.33/blib/arch/auto/Apache/Request/Request.so 
/home/crux/RPM/BUILD/libapreq-1.33/blib/arch/auto/Apache/Cookie/Cookie.so
/home/crux/RPM/BUILD/libapreq-1.33/blib/arch/auto/Apache/Request/Request.so: 
undefined reference to `ap_table_do'
/home/crux/RPM/BUILD/libapreq-1.33/blib/arch/auto/Apache/Request/Request.so: 
undefined reference to `ap_log_rerror'
/home/crux/RPM/BUILD/libapreq-1.33/blib/arch/auto/Apache/Request/Request.so: 
undefined reference to `ap_table_get'
/home/crux/RPM/BUILD/libapreq-1.33/blib/arch/auto/Apache/Request/Request.so: 
undefined reference to `ap_make_array'
/home/crux/RPM/BUILD/libapreq-1.33/blib/arch/auto/Apache/Request/Request.so: 
undefined reference to `ap_palloc'
...

Замена макроса %perl_vendor_build на простенькое `perl Makefile.PL && 
make` приводит к нормальной сборке и нормальному функционированию пакета 
в целом.
Есть идеи?

-- 
С уважением, Владимир Леттиев aka crux <crux@gorodmasterov.com>

[devel] Re: q: _perl_vendor_check_dso problems

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

On Mon, Sep 26, 2005 at 04:52:33PM +0400, Vladimir Lettiev wrote:
> на этапе проверки dso вылезает жуть вида:
> 
> ...
> + gcc ldtest.c -lperl 
> /home/crux/RPM/BUILD/libapreq-1.33/blib/arch/auto/Apache/Request/Request.so 
> /home/crux/RPM/BUILD/libapreq-1.33/blib/arch/auto/Apache/Cookie/Cookie.so
> /home/crux/RPM/BUILD/libapreq-1.33/blib/arch/auto/Apache/Request/Request.so: 
> undefined reference to `ap_table_do'
> /home/crux/RPM/BUILD/libapreq-1.33/blib/arch/auto/Apache/Request/Request.so: 
> undefined reference to `ap_log_rerror'
> /home/crux/RPM/BUILD/libapreq-1.33/blib/arch/auto/Apache/Request/Request.so: 
> undefined reference to `ap_table_get'
> /home/crux/RPM/BUILD/libapreq-1.33/blib/arch/auto/Apache/Request/Request.so: 
> undefined reference to `ap_make_array'
> /home/crux/RPM/BUILD/libapreq-1.33/blib/arch/auto/Apache/Request/Request.so: 
> undefined reference to `ap_palloc'
> ...
> 
> Замена макроса %perl_vendor_build на простенькое `perl Makefile.PL && 
> make` приводит к нормальной сборке и нормальному функционированию пакета 
> в целом.
> Есть идеи?

А кто собственно предоставляет функции (символы) ap_table_do,
ap_log_rerror и т.д.  Пушкин?

Слинковаться надо с библиотекой, в которой эти функции.
Попробуйте %perl_vendor_build LIBS=-lapr

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: q: _perl_vendor_check_dso problems

[Vladimir Lettiev]

Alexey Tourbin пишет:
> On Mon, Sep 26, 2005 at 04:52:33PM +0400, Vladimir Lettiev wrote:
> 
>>на этапе проверки dso вылезает жуть вида:
>>...
>>+ gcc ldtest.c -lperl 
>>/home/crux/RPM/BUILD/libapreq-1.33/blib/arch/auto/Apache/Request/Request.so 
>>/home/crux/RPM/BUILD/libapreq-1.33/blib/arch/auto/Apache/Cookie/Cookie.so
>>/home/crux/RPM/BUILD/libapreq-1.33/blib/arch/auto/Apache/Request/Request.so: 
>>undefined reference to `ap_table_do'
>>...
>>Есть идеи?
> 
> 
> А кто собственно предоставляет функции (символы) ap_table_do,
> ap_log_rerror и т.д.  Пушкин?
> 
> Слинковаться надо с библиотекой, в которой эти функции.
> Попробуйте %perl_vendor_build LIBS=-lapr

Нет, безрезультатно.
Похоже все указанные функции проглядываются в *.h файлах, которые 
принадлежат пакету apache-mod_perl.
Это где-то в этом районе:
/usr/lib/perl5/vendor_perl/i386-linux/auto/Apache/include/

-- 
С уважением, Владимир Леттиев aka crux <crux@gorodmasterov.com>

[devel] Re: q: _perl_vendor_check_dso problems

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3372 bytes --]

On Mon, Sep 26, 2005 at 05:23:23PM +0400, Vladimir Lettiev wrote:
> Нет, безрезультатно.
> Похоже все указанные функции проглядываются в *.h файлах, которые 
> принадлежат пакету apache-mod_perl.

Эти функции *должны* быть в какой-то *.so библиотеке.  Если эта
библиотека публичная, то есть предназначена для непосредственной
линковки, то лучше всего с ней слинковаться.

> Это где-то в этом районе:
> /usr/lib/perl5/vendor_perl/i386-linux/auto/Apache/include/

Если же это библиотека типа loadable module, то есть не предназначена
для непосредственной линковки, то можно "подстроить" проверку.  Пример
из perl-Gtk2-GladeXML.spec:

EXTRA_BLIBS=`ls %perl_vendor_autolib/{Glib/Glib,Gtk2/Gtk2}.so`
%perl_vendor_build

При загрузке Glib.so и Gtk2.so используется RTLD_GLOBAL, это такой
хитрый/окольный ELF механизм для глобального импорта символов из
объекта, который загружается с помощью dlopen().

Поиск по символам показывает, что функции ap_table_do и др. находятся
в /usr/lib/apache/libhttpd.so:

apache  /usr/lib/apache/libhttpd.so     T       ap_table_do
apache-mod_perl /usr/sbin/httpd-perl    T       ap_table_do

Я вообще не знаю, как всё это работает, то есть как в процессе
динамической линковки подцепляется libhttpd.so.  Если есть уверенность,
что оно действительно работает, то проще всего модифицировать проверку:

EXTRA_BLIBS=`ls %_libdir/apache/libhttpd.so`
%perl_vendor_build

Но у libhttpd.so в свою очередь тоже есть undefined symbols:

$ ldd -r /usr/lib/apache/libhttpd.so 2>&1 |head
        libc.so.6 => /lib/i686/libc.so.6 (0x40074000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
undefined symbol: mm_core_delete        (/usr/lib/apache/libhttpd.so)
undefined symbol: dlerror       (/usr/lib/apache/libhttpd.so)
undefined symbol: MM_create     (/usr/lib/apache/libhttpd.so)
undefined symbol: deflate       (/usr/lib/apache/libhttpd.so)
undefined symbol: mm_maxsize    (/usr/lib/apache/libhttpd.so)
undefined symbol: mm_core_align2page    (/usr/lib/apache/libhttpd.so)
undefined symbol: MM_destroy    (/usr/lib/apache/libhttpd.so)
undefined symbol: mm_create     (/usr/lib/apache/libhttpd.so)
$

Всё это как-то криво и работает "на честном слове и на одном крыле".
Символы MM_create и др. есть и libmm:

libmm   /usr/lib/libmm.so.1.3.0 T       MM_create

Если добавить в EXTRA_BLIBS libmm, то проверка опять не проходит:

$ gcc ~/ldtest.c /usr/lib/apache/libhttpd.so /usr/lib/libmm.so
/usr/lib/apache/libhttpd.so: undefined reference to `dlerror'
/usr/lib/apache/libhttpd.so: undefined reference to `deflate'
/usr/lib/apache/libhttpd.so: undefined reference to `dlclose'
/usr/lib/apache/libhttpd.so: undefined reference to `crc32'
/usr/lib/apache/libhttpd.so: undefined reference to `dlopen'
/usr/lib/apache/libhttpd.so: undefined reference to `deflateInit2_'
/usr/lib/apache/libhttpd.so: undefined reference to `crypt'
/usr/lib/apache/libhttpd.so: undefined reference to `dlsym'
/usr/lib/apache/libhttpd.so: undefined reference to `deflateEnd'

Опыты показывают, что проверка в конечном счете будет работать так:

$ gcc ~/ldtest.c /usr/lib/apache/libhttpd.so -lmm -ldl -lcrypt -lz

То есть придётся написать 

EXTRA_BLIBS='/usr/lib/apache/libhttpd.so -lmm -ldl -lcrypt -lz'
%perl_vendor_build

Излишне говорить, что всё это сводит на нет смысл проверки.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: q: _perl_vendor_check_dso problems

[Alexey I.Froloff]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

* Alexey Tourbin <at@> [050926 18:02]:
> Поиск по символам показывает, что функции ap_table_do и др. находятся
> в /usr/lib/apache/libhttpd.so:

> apache  /usr/lib/apache/libhttpd.so     T       ap_table_do
> apache-mod_perl /usr/sbin/httpd-perl    T       ap_table_do
Как раз таки /usr/sbin/httpd-perl, а не
/usr/lib/apache/libhttpd.so...

-- 
Regards, Sir Raorn.
-------------------
Если кто захочет помочь/советовать -- willkommen.
		-- peet in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: q: _perl_vendor_check_dso problems

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

On Mon, Sep 26, 2005 at 05:57:08PM +0400, Alexey Tourbin wrote:
> EXTRA_BLIBS='/usr/lib/apache/libhttpd.so -lmm -ldl -lcrypt -lz'
> %perl_vendor_build
> 
> Излишне говорить, что всё это сводит на нет смысл проверки.

$ ldd -r /usr/lib/apache/libhttpd.so 2>&1 |grep -wc undefined
50

Имеет смысл повесить на пакет `rpmquery -f /usr/lib/apache/libhttpd.so`
багу.

Моё терпение скоро иссякнет, и rpmbuild начнёт нарушителей давить.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: q: _perl_vendor_check_dso problems

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

On Mon, Sep 26, 2005 at 06:13:28PM +0400, Dmitry V. Levin wrote:
> > EXTRA_BLIBS='/usr/lib/apache/libhttpd.so -lmm -ldl -lcrypt
> > -lz' %perl_vendor_build
> > Излишне говорить, что всё это сводит на нет смысл проверки.
> $ ldd -r /usr/lib/apache/libhttpd.so 2>&1 |grep -wc undefined
> 50
> Имеет смысл повесить на пакет `rpmquery -f
> /usr/lib/apache/libhttpd.so` багу.

И что с ней потом делать?

> Моё терпение скоро иссякнет, и rpmbuild начнёт нарушителей давить.

Ну отправлю в orphaned, делов-то.

По сути выражайся, иначе реакция ациклического Sn1-элиминирования
данного структурного недостатка субстрата будет ингибирована.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
 ----       visit our conference (Oct 1):
--          http://conference.osdn.org.ua

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: q: _perl_vendor_check_dso problems

[Alexey I.Froloff]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

* Dmitry V. Levin <ldv@> [050926 18:17]:
> $ ldd -r /usr/lib/apache/libhttpd.so 2>&1 |grep -wc undefined
> 50
> Имеет смысл повесить на пакет `rpmquery -f /usr/lib/apache/libhttpd.so`
> багу.
А это не библиотека.  Это "плагин".  А в случае mod_perl, который
тут обсуждается, все "недостающие" символы провайдятся самим
/usr/sbin/httpd-perl...

$ ldd -r /usr/lib/quakeforge/*.so 2>&1 |grep -wc undefined
134

-- 
Regards, Sir Raorn.
-------------------
> Я это и имел в виду, что не придётся форматировать DVD вручную.
А я не знал. Иногда полезно отвечать на вопросы, кто-нибудь поправит.
		-- yust in community@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: q: _perl_vendor_check_dso problems

[Alexey Tourbin]

[-- Attachment #1.1: Type: text/plain, Size: 1087 bytes --]

On Mon, Sep 26, 2005 at 06:13:28PM +0400, Dmitry V. Levin wrote:
> $ ldd -r /usr/lib/apache/libhttpd.so 2>&1 |grep -wc undefined
> 50
> 
> Имеет смысл повесить на пакет `rpmquery -f /usr/lib/apache/libhttpd.so`
> багу.
> 
> Моё терпение скоро иссякнет, и rpmbuild начнёт нарушителей давить.

Так как "задавить" /usr/lib/apache/libhttpd.so?  Это же не публичная
библиотека (в частности, её нет в /etc/ld.so.cache).  К libhttpd.so
можно применить только очень слабую проверку.

То есть нужна более сложная модель, в которой можно выдвигать
предположения типа "libhttpd.so ни слинкована с libz.so" и как-нибудь
эти предположения проверять, возможно, методом резолюций.  Но это очень
сложно, я об этом даже думать не могу. :)

PS: вот на чем остановилось verify_elfsym.  Осталось сделать две вещи:
1) Вместо "${elf##*/lib/lib*.so*}" написать предикат elf1_is_public_library
2) Подумать, как в brp-alt "протащить" полный список предоставляемых
символов на всём репозитарии; вместо полного списка (60M) можно сделать
bloom filter (2M), но проблема по существу остается.

[-- Attachment #1.2: verify_elfsym --]
[-- Type: text/plain, Size: 3172 bytes --]

#!/bin/sh -ef

. /usr/lib/rpm/functions
[ -z "$RPM_BUILD_ROOT" ] || ValidateBuildRoot

RTLD=/lib/ld-linux.so.2
RTLD_libpath=/lib:/usr/lib:/usr/X11R6/lib

elf1_libpath()
{
	local elf="$1" libpath="$RTLD_libpath"
	[ -z "$LD_LIBRARY_PATH" ] ||
		libpath="$LD_LIBRARY_PATH:$libpath"
	[ -z "$RPM_FINDPROV_LIB_PATH" ] ||
		libpath="$RPM_FINDPROV_LIB_PATH:$libpath"
	local info= rpath=
	info="$(objdump -p "$elf")" || return
	rpath="$(echo "$info" |awk '($1=="RPATH"){printf "%s:", $2}')"
	[ -z "$rpath" ] ||
		libpath="$rpath$libpath"
	if [ -n "$RPM_BUILD_ROOT" ]; then
		local BR_libpath= path= IFS=:
		for path in $libpath; do
			BR_libpath="$BR_libpath:$RPM_BUILD_ROOT$path"
		done
		libpath="${BR_libpath#:}:$libpath"
	fi
	echo "$libpath"
}

elf1_ldd()
{
	local elf="$1" libpath=
	libpath="$(elf1_libpath "$elf")" || return
	LD_TRACE_LOADED_OBJECTS=1 LD_WARN=1 LD_BIND_NOW=1 LD_VERBOSE= \
		"$RTLD" --library-path "$libpath" --inhibit-rpath "$elf" "$elf"
}

elf1_undefined_symbols()
{
	local elf="$1" out=
	if ! out="$(elf1_ldd "$elf" 2>&1)"; then
		echo "$PROG: $elf: ldd failed:" >&2
		echo "$out" >&2
		return 2
	fi
	if [ -n "$out" -a -z "${out##* not found*}" ]; then
		echo "$PROG: $elf: unresolved dependencies:" >&2
		echo "$out" |grep -F ' not found' >&2
		return 1
	fi
	if [ -n "$out" -a -z "${out##*undefined symbol:*}" ]; then
		echo "$out" |awk '/^undefined symbol:/ {
			gsub("^[(]|[)]$", "", $NF)
			print $3 "\t" $NF }'
	fi
}

elf1_verify_strict()
{
	local elf="$1" err=
	err="$(elf1_undefined_symbols "$elf")" || return 2
	[ -n "$err" ] || return 0
	local sym= obj=
	while IFS=$'\t' read -r sym obj; do
		[ "$obj" = "$elf" ] &&
			echo "$PROG: $elf: undefined symbol: $sym" >&2 ||
			echo "$PROG: $elf: undefined symbol: $sym ($obj)" >&2
	done <<<"$err"
	return 1
}

elf1_verify_relaxed()
{
	local elf="$1" symtab="$2" err=
	err="$(elf1_undefined_symbols "$elf")" || return 2
	[ -n "$err" ] || return 0
	local rc=0 sym= obj=
	while IFS=$'\t' read -r sym obj; do
		if [ "$obj" != "$elf" ]; then
			echo "$PROG: $elf: undefined symbol: $sym ($obj)" >&2
			rc=1
		elif ! bloom -e "$sym" "$symtab"; then
			echo "$PROG: $elf: undefined symbol: $sym" >&2
			rc=1
		fi
	done <<<"$err"
	return $rc
}	

: ${VERIFY_ELF_SYM:=normal}
case "$VERIFY_ELF_SYM" in
	strict|normal|relaxed) : ;;
	no|none|skip) exit 0 ;;
	*) Fatal "Unrecognized $PROG method: $VERIFY_ELF_SYM" ;;
esac

rc=0 symtab="$1"
shift

for elf; do
	if ! type="$(file -bL "$elf")"; then
		echo "$PROG: $elf: $type" >&2
		rc=1
		continue
	fi
		
	[ -n "$type" ] || continue
	[ -z "${type##*ELF*dynamic*}" -o -z "${type##*ELF*shared*}" ] || continue

	if [ "$VERIFY_ELF_SYM" = strict ]; then
		elf1_verify_strict "$elf" || rc=1
	elif [ "$VERIFY_ELF_SYM" = relaxed ]; then
		elf1_verify_relaxed "$elf" "$symtab" || rc=1
	elif [ -z "${type##*ELF*executable*}" ]; then
		elf1_verify_strict "$elf" || rc=1
	elif [ -z "${type##*ELF*shared*}" -a -z "${elf##*/lib/lib*.so*}" ]; then
		elf1_verify_strict "$elf" || rc=1
	else
		elf1_verify_relaxed "$elf" "$symtab" || rc=1
	fi	
done
exit $rc

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: q: _perl_vendor_check_dso problems

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

On Mon, Sep 26, 2005 at 06:25:24PM +0400, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [050926 18:17]:
> > $ ldd -r /usr/lib/apache/libhttpd.so 2>&1 |grep -wc undefined
> > 50
> > Имеет смысл повесить на пакет `rpmquery -f /usr/lib/apache/libhttpd.so`
> > багу.
> А это не библиотека.  Это "плагин".  А в случае mod_perl, который

OK, плагин использует символы из zlib, но не слинкован с zlib.
Возможно, в той среде, куда этот плагин загружают, zlib уже загружен.
А может быть и не загружен.  Это правильно?

Кроме того, летит к чертям symbol versioning.  То есть если плагин
использует newZlibFunction, то при линковке с -lz он получит версионную
зависимость на newZlibFunction@ZLIB_2.0.  А без линковки с -lz он ничего
не получит.

> тут обсуждается, все "недостающие" символы провайдятся самим
> /usr/sbin/httpd-perl...

Это две разные проблемы.  Я сейчас заостряю внимание на том, что
libhttpd.so не слинкован с библиотеками, чьи функции он использует.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] verify-elf

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]

On Mon, Sep 26, 2005 at 06:41:41PM +0400, Alexey Tourbin wrote:
> On Mon, Sep 26, 2005 at 06:13:28PM +0400, Dmitry V. Levin wrote:
> > $ ldd -r /usr/lib/apache/libhttpd.so 2>&1 |grep -wc undefined
> > 50
> > 
> > Имеет смысл повесить на пакет `rpmquery -f /usr/lib/apache/libhttpd.so`
> > багу.
> > 
> > Моё терпение скоро иссякнет, и rpmbuild начнёт нарушителей давить.
> 
> Так как "задавить" /usr/lib/apache/libhttpd.so?  Это же не публичная
> библиотека (в частности, её нет в /etc/ld.so.cache).  К libhttpd.so
> можно применить только очень слабую проверку.

Какя разница, если у ELF shared object есть undefined symbol из zlib,
разве это не достаточно веская причина, чтобы давить?

> PS: вот на чем остановилось verify_elfsym.  Осталось сделать две вещи:
> 1) Вместо "${elf##*/lib/lib*.so*}" написать предикат elf1_is_public_library

Не проблема.

> 2) Подумать, как в brp-alt "протащить" полный список предоставляемых
> символов на всём репозитарии; вместо полного списка (60M) можно сделать
> bloom filter (2M), но проблема по существу остается.

Тоже не проблема, файл i586/base/contents_index того же размера.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: verify-elf

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2060 bytes --]

On Mon, Sep 26, 2005 at 07:26:23PM +0400, Dmitry V. Levin wrote:
> > Так как "задавить" /usr/lib/apache/libhttpd.so?  Это же не публичная
> > библиотека (в частности, её нет в /etc/ld.so.cache).  К libhttpd.so
> > можно применить только очень слабую проверку.
> 
> Какя разница, если у ELF shared object есть undefined symbol из zlib,
> разве это не достаточно веская причина, чтобы давить?

Тогда нужно обобщить: если у ELF shared object есть undefined symbol,
который предоставляет одна и только одна публичная библиотека (и никто
другой), то такой ELF shared object нужно давить, потому что он не
слинкован с этой библиотекой, тогда как очевидно должен быть слинкован.

Теперь, как это закодить на шелле?  Сложновато получается.
С другой стороны, кто-то может предоставлять символы из zlib.

Я пока предлагаю сделать сильную проверку только для исполняемых файлов
и публичных библиотек.  На самом деле исполняемые файлы проверять не
обязательно, так как сам факт того, что их удалось слинковать, уже, как
правило, означает, что в них нет undefined symbols.  Но эта проверка 
актуальна для уже собранных пакетов, в изменившейся среде.  Проверка для
публичных библиотек по требованию похожа на -Wl,-z,defs.

Для всего остального можно делать только слабую проверку на основе
полного списка предоставляемых символов.  Иначе можно задавить
что-нибудь "не то".

> > 2) Подумать, как в brp-alt "протащить" полный список предоставляемых
> > символов на всём репозитарии; вместо полного списка (60M) можно сделать
> > bloom filter (2M), но проблема по существу остается.
> Тоже не проблема, файл i586/base/contents_index того же размера.

Ещё этот список нужно "наращивать" ELF'ами, которые лежат в buildroot'е.
Иначе опять появляется вероятность задавить что-нибудь не то.
Наращивание списка должно быть реализовано не в verify-elfsym, а где-то
ещё.  Но это уже будет видно со временем.  Сейчас нужно наладить
регулярные пересборки и сделать несколько "холостых" пересборок (без
проверки ELF'ов), чтобы закрыть старые ошибки.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: verify-elf

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2265 bytes --]

On Mon, Sep 26, 2005 at 08:05:59PM +0400, Alexey Tourbin wrote:
> On Mon, Sep 26, 2005 at 07:26:23PM +0400, Dmitry V. Levin wrote:
> > > Так как "задавить" /usr/lib/apache/libhttpd.so?  Это же не публичная
> > > библиотека (в частности, её нет в /etc/ld.so.cache).  К libhttpd.so
> > > можно применить только очень слабую проверку.
> > 
> > Какя разница, если у ELF shared object есть undefined symbol из zlib,
> > разве это не достаточно веская причина, чтобы давить?
> 
> Тогда нужно обобщить: если у ELF shared object есть undefined symbol,
> который предоставляет одна и только одна публичная библиотека (и никто
> другой), то такой ELF shared object нужно давить, потому что он не
> слинкован с этой библиотекой, тогда как очевидно должен быть слинкован.
> 
> Теперь, как это закодить на шелле?  Сложновато получается.
> С другой стороны, кто-то может предоставлять символы из zlib.

"Я вам попредоставляю".

> Я пока предлагаю сделать сильную проверку только для исполняемых файлов
> и публичных библиотек.  На самом деле исполняемые файлы проверять не
> обязательно, так как сам факт того, что их удалось слинковать, уже, как
> правило, означает, что в них нет undefined symbols.  Но эта проверка 
> актуальна для уже собранных пакетов, в изменившейся среде.  Проверка для
> публичных библиотек по требованию похожа на -Wl,-z,defs.
> 
> Для всего остального можно делать только слабую проверку на основе
> полного списка предоставляемых символов.  Иначе можно задавить
> что-нибудь "не то".

Я согласен.

> > > 2) Подумать, как в brp-alt "протащить" полный список предоставляемых
> > > символов на всём репозитарии; вместо полного списка (60M) можно сделать
> > > bloom filter (2M), но проблема по существу остается.
> > Тоже не проблема, файл i586/base/contents_index того же размера.
> 
> Ещё этот список нужно "наращивать" ELF'ами, которые лежат в buildroot'е.
> Иначе опять появляется вероятность задавить что-нибудь не то.
> Наращивание списка должно быть реализовано не в verify-elfsym, а где-то
> ещё.  Но это уже будет видно со временем.  Сейчас нужно наладить
> регулярные пересборки и сделать несколько "холостых" пересборок (без
> проверки ELF'ов), чтобы закрыть старые ошибки.

Конечно.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: q: _perl_vendor_check_dso problems

[Konstantin A.Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

Hi Alexey!

Monday 26, at 05:57:08 PM you wrote:

> /usr/lib/apache/libhttpd.so: undefined reference to `dlerror'
> /usr/lib/apache/libhttpd.so: undefined reference to `deflate'
> /usr/lib/apache/libhttpd.so: undefined reference to `dlclose'
> /usr/lib/apache/libhttpd.so: undefined reference to `crc32'
> /usr/lib/apache/libhttpd.so: undefined reference to `dlopen'
> /usr/lib/apache/libhttpd.so: undefined reference to `deflateInit2_'
> /usr/lib/apache/libhttpd.so: undefined reference to `crypt'
> /usr/lib/apache/libhttpd.so: undefined reference to `dlsym'
> /usr/lib/apache/libhttpd.so: undefined reference to `deflateEnd'
похоже на статический mod_deflate ;)

-- 
WBR, Konstantin	      chat with ==>ICQ: 109916175
     Lepikhov,	      speak  to ==>JID: lakostis@jabber.org
aka L.A. Kostis       write  to ==>mailto:lakostis@pisem.net.nospam

...The information is like the bank... 			  (c) EC8OR

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: q: _perl_vendor_check_dso problems

[Igor Zubkov]

В сообщении от Понедельник, 26-Сен-2005 17:25 Alexey I.Froloff написал(a):
> > $ ldd -r /usr/lib/apache/libhttpd.so 2>&1 |grep -wc undefined
> > 50
> > Имеет смысл повесить на пакет `rpmquery -f /usr/lib/apache/libhttpd.so`
> > багу.
>
> А это не библиотека.  Это "плагин".  А в случае mod_perl, который
> тут обсуждается, все "недостающие" символы провайдятся самим
> /usr/sbin/httpd-perl...
>
> $ ldd -r /usr/lib/quakeforge/*.so 2>&1 |grep -wc undefined
> 134

Аналогично...

[icesik@localhost icesik]$ ldd -r /usr/lib/games/quake2/*.so | grep undef
undefined symbol: pow   (/usr/lib/games/quake2/ref_glx.so)
undefined symbol: UpdateHardwareGamma   (/usr/lib/games/quake2/ref_sdlgl.so)
undefined symbol: pow   (/usr/lib/games/quake2/ref_softx.so)
[icesik@localhost icesik]$ 

И что с этим делать? Оно таки даже работает. ;-)

p.s.: а чего это *.so от quakeforge лежат в /usr/lib/quakeforge/ а не 
в /usr/lib/games/quakeforge/ ?

-- 
Now playing: Evanescence [] [] Solitude