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. ĸen -- Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir. I can do the rite of k'zakra, I know the secrets of h'ragna, I can ha'lk my g'rakha correctly ... I am a dwarf Captain Carrot Ironfoundersson (in The Fifth Elephant) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
