Hello Guys, I really appreciated your help on this story, I (strongly) believe I found the solution and restarted the full (800) build (no laughs in the back of the room please) again. It is a 3 hours process (before I can get the expected result/proof), I am confident enough about the analyze to be correct, so lets take the risk.
Problem was: - Why, among the 800 packages build, libreoffice was the only one requesting rtld(GNU_HASH), rtld being something within the glibc library. - why the trouble is not reported during the build process. - why the libreoffice generated binaries, while "something missing" is reported, are working fine. An easy/paranoid solution, was to say something calling an old glibc library was plugged as it in executable/library within the libreoffice binaries and this is detected by the RPM scanning, as to be an alien requirement!. A bold proposal I agree...but not impossible. Ken proposed, it could be a false alarm caused by the fact that I am building in "memory only". I have enough memory (64G) and the server is using multiple virtual (vzgot, a kind of LXC), so memory is always under heavy load and an hardware trouble will show up on other tasks too.. rtld RPM report is steady among all the build, so hardware defect cause is a very very remote one. Well..... rtld(GNU_HASH) is not something really existing, it is an rpm marker. glibc provide 2 kind of hashing functions to access libraries header. the sysv and the gnu one. objdump -h /usr/bin/vi | grep hash2 .hash 00000680 00000000004002e8 00000000004002e8 000002e8 2**3 3 .gnu.hash 00000050 0000000000400968 0000000000400968 00000968 2**3
within BLFS, packages build directives never define a specific hash function to the linker (correct me if wrong), such the default option is "both" (this, to be double checked).
But, within libreoffice building sequences (in the ugly addons), specific directive are given to the linker. A grep of "hash" within libreoffice give multiple occurrence of hash directives... Grep result for word hash (partial) ;------------------------------------------------- /distro-configs/LibreOfficeLinux.conf$(if $(filter TRUE,$(HAVE_LD_HASH_STYLE)),-Wl$(COMMA)--hash-style=$(WITH_LINKER_HASH_STYLE)) \
./external/icu/ExternalProject_icu.mk
-Wl,--hash-style=$(WITH_LINKER_HASH_STYLE) \
./solenv/gbuild/platform/solaris.mk
-Wl,--hash-style=$(WITH_LINKER_HASH_STYLE)
Fall back to --hash-style=sysv when gnu is not supported
Fall back to --hash-style=sysv when gnu is not supported
use --hash-style=gnu linking when supported
;-------------------------------------------------
So as the book glibc is gnu hash compatible, link is done
using gnu hash....
Then RPM, is complaining not finding the gnu hash function,
even if this one is really existing in glibc.
The solution, is to "hardcode" the fact glibc is gnu hash
compatible by inserting "Provides: rtld(GNU_HASH)" within
glibc spec file (a simple marker).
OK guys, be nice with me, I write my spec file by taking
the book directives (almost at the letter), never adding
something I do not understand or/and coming from other
distribution spec file.
So, I think, this explain all data collected....
Let wait for the build to be completed.....
:)
Should we specify, in book, a Recommended --hash-style
within LDFLAGS?
;)
--
seen "Linux from scratch" and looking for ISO files
www.osukiss.org
smime.p7s
Description: S/MIME Cryptographic Signature
-- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
