Re: [devel] Проблема при сборке newmon 27.0

[Ivan Zakharyaschev <imz@altlinux.org>]

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

On Sat, 3 Dec 2016, Hihin Ruslan wrote:

>  В сообщении от 2 декабря 2016 Ivan Zakharyaschev написал(a):

>> Чтобы всё было хорошо и красиво, при моём поверхнстном взгляде
>> на последнюю сборку 27.0.2-alt1 мне кажется, что не хватает
>> аналогичного (как у всех других библиотек, которые он носит с
>> собой) RUNPATH у libsoftokn3.so:
> Вот это почему-то пока не получается. Пока получилось или собрать

Я заинтересовался, в чём там хитрость с одной библиотекой.

Посмотрел лог поледней сборки 
http://git.altlinux.org/tasks/archive/done/_169/173812/build/100/x86_64/log 
. Понял, что это библиотека из состава libnss. Посмотрел .spec 
https://packages.altlinux.org/en/Sisyphus/srpms/palemoon/spec , увидел, 
что rpath передаётся через LDFLAGS. В логе видно, что до сборки libnss оно 
не доезжает (перекрывается):

make[5]: Entering directory 
`/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/config/external/nss'
rm -f libnss.a
/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/_virtualenv/bin/python 
/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/config/expandlibs_gen.py -o 
libnss.a.desc
mkdir -p '../../../security/nss/lib/ckfw/builtins/'
LDFLAGS=-Wl,--build-id make -C 
/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/security/nss/lib libs  CC=' 
gcc' SOURCE_MD_DIR=/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist 
SOURCE_MDHEADERS_DIR=/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist/include/nspr 
DIST=/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist 
NSPR_INCLUDE_DIR=/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist/include/nspr 
NSPR_LIB_DIR=/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist/lib 
MOZILLA_CLIENT=1 NO_MDUPDATE=1 NSS_ENABLE_ECC=1 SQLITE_LIB_NAME=mozsqlite3 
SQLITE_INCLUDE_DIR=/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist/include 
topsrcdir='/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon' 
BUILD='/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/security/$(subst 
$(topsrcdir)/security/,,$(CURDIR))' BUILD_TREE='$(BUILD)' 
OBJDIR='$(BUILD)' DEPENDENCIES='$(BUILD)/.deps' 
SINGLE_SHLIB_DIR='$(BUILD)' 
SOURCE_XP_DIR=/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist 
BUILD_OPT=1 OPT_CODE_SIZE=1 NS_USE_GCC=1 USE_64=1 NSS_ENABLE_ZLIB= 
PROGRAMS= CHECKLOC= FREEBL_NO_DEPEND=0 FREEBL_LOWHASH=1 
NSS_NO_PKCS11_BYPASS=1 
PUBLIC_EXPORT_DIR='/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist/include/$(MODULE)' 
SOURCE_XPHEADERS_DIR='$(SOURCE_XP_DIR)/include/$(MODULE)' 
MODULE_INCLUDES='$(addprefix -I$(SOURCE_XP_DIR)/include/,$(REQUIRES))' 
MAKE_OBJDIR='$(INSTALL) -D $(OBJDIR)' TARGETS='$(LIBRARY) 
$(SHARED_LIBRARY) $(PROGRAM)' 
NSINSTALL='/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/config/nsinstall'

Подумал, что это вообще не хорошо, если ставить перед собой задачу носить 
свой libnss с собой, что у всех библиотек из его состава не будет 
RPATH/RUNPATH и lib.req проставит все их зависимости между собой на 
системные библиотеки из состава libnss (оно попадает в сборочную среду). 
Как оно в реальности будет работать, я даже не знаю: системные или свои 
библиотеки будут загружаться... В общем, непредсказуемая путаница. (fgrep 
softok /ALT/Sisyphus/{noarch,x86_64}/base/contents_index показывает, что 
подобным образом устроен и пакет firefox-gost, но там не ставят 
RPATH/RUNPATH. Зависимостей на системные libnss там, правда, тоже не 
генерируют. Наверное, это работает благодаря другим механизмам, но плохо 
поддаётся автоматической проверке с помощью verify-elf.)

(А если не ставить перед собой такую задачу -- использовать свой libnss, 
то и паковать эти библиотеки не стоит.)

С помощью git grep LDFLAGS нашёл в исходниках место, где перекрывают 
LDFLAGS:

palemoon/security/build/Makefile.in-ifneq (,$(filter 
%--build-id,$(LDFLAGS)))
palemoon/security/build/Makefile.in:DEFAULT_GMAKE_ENV = 
LDFLAGS=-Wl,--build-id
palemoon/security/build/Makefile.in-endif
palemoon/security/build/Makefile.in-
--
palemoon/security/build/Makefile.in-
palemoon/security/build/Makefile.in-$(foreach p,libs export 
private_export,$(addprefix $(p)-,$(NSS_DIRS))):
palemoon/security/build/Makefile.in:    $(DEFAULT_GMAKE_ENV) $(MAKE) -C 
$(NSS_SRCDIR)/security/$* $(@:-$*=) $(DEFAULT_GMAKE_FLAGS)
palemoon/security/build/Makefile.in-

А в Google находится патч, убирающий это для сборки для RH, правда, без 
комментария, зачем это им было нужно:

https://git.centos.org/blob/rpms!firefox.git/4cf60e2cb865301a78018acf20fec7760c8927a9/SOURCES!build-el5-nss.patch

diff -up mozilla-aurora/config/external/nss/Makefile.in.build-el5-nss 
mozilla-aurora/config/external/nss/Makefile.in
--- mozilla-aurora/config/external/nss/Makefile.in.build-el5-nss 
2016-01-26 10:25:01.770613169 +0100
+++ mozilla-aurora/config/external/nss/Makefile.in	2016-01-26 
10:25:12.824599219 +0100
@@ -298,7 +298,7 @@ NSS_DIRS += \
  endif

  ifneq (,$(filter %--build-id,$(LDFLAGS)))
-DEFAULT_GMAKE_ENV = LDFLAGS=-Wl,--build-id
+#DEFAULT_GMAKE_ENV = LDFLAGS=-Wl,--build-id
  endif

  ifdef MOZ_FOLD_LIBS

Кажется, с этим патчем rpath из .spec доберётся и до библиотек nss. (Там 
их больше одной этой, но из-за того, что libnss была в сборочной среде, мы 
не видели сообщения про unresolved symbols про них.)

-- 
Best regards,
Ivan