On 27/08/2019 04:14, Ken Moffat via blfs-dev wrote: > On Mon, Aug 26, 2019 at 08:22:34PM -0400, Jean-Marc Pigeon via blfs-dev wrote: >> >> 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 hash >> 2 .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? >> ;) > > > Possibly relevant background to this, > http://lists.llvm.org/pipermail/llvm-dev/2017-October/117968.html > (about lld, the clang linker) says > |>> > GNU_HASH format is a better version of hash table ( > |>> https://sourceware.org/ml/binutils/2006-10/msg00377.html). > |>> > > |>> > We have --hash-style=sysv currently set by default in LLD. > |>> > Though recently (see https://bugs.llvm.org//show_bug.cgi?id=34712) GNU > |>> linkers switched to use > |>> > ".gnu.hash" section format in addition to normally used classic ".hash". > |>> > So they defaults --hash-style to "both" and this looks to be released > |>> with binutils 2.30. > |>> > > |>> > I think we can switch LLD either to "both" or probably to "gnu" by > |>> default as well. > > And the output from libreoffice configuration is > checking for --hash-style gcc linker support... gnu > > And that goes back to at least libreoffice-6.0.1.1 on LFS-8.2 (our > first release with binutils-2.30). Nope, tell a lie, it goes > further back (my earliest libreoffice log on this machine is from > LFS-7.9, building 5.1.0.3 with binutils-2.26). > > The sourceware link is from 2006, so obviously MUCH earlier than > binutils-2.30. Maybe somewhere in the binutils-2.16 or 2.17 range. > the link does go into the details. > > Alternativelt, an explanation (on a quick glance, gentoo-based) of > why the gnu hash style is "better" is within > https://flameeyes.blog/2010/09/09/are-we-done-with-ldflags/ > > Brief summary: modern linux systems will use the .gnu.hash which > will give faster loading by the runtime linker for (C++) programs > with a lot of very long similar symbols. Old (in our terms, I guess > that should be "very old") x86 linux systems will use the sysv hash > style. > > So the default of both will use the faster method, except when > loading binaries which have been compiled with only the old sysv > hash. > > Oh, and the development in that blog link was related to when > development was still happening at openoffice.org so that is why > they turn up in so many google results for this. > > A further glance at the blog (the part re FreeBSD) implies that rtld > built only for gnu hash can probably link even if the expected > section is missing - but it will do a linear search! > > Possibly, forcing --hash-style=gnu might save a little build time > and space. But I don't think the effort of measuring that will be > worth the possible gains. And probably not everything respects the > user's LDFLAGS. > > Anyway, thanks for sharing your findings (and also to Pierre for > explaining what rtld is), I've learned from this.
Great thread, thanks Jean-Marc and Ken. I learned a lot too. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
