Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , knowledge, explanations and solution
On 8/26/2019 7:22 PM, Jean-Marc Pigeon via blfs-dev wrote: 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). Not exactly. I think you've misunderstood my suggestion here. Let me try to explain the two parts separately. The 'solution' above was RedHat's (and later SUSE's) solution to account for a change in glibc packages after the new hash functionality became available. I'm a bit fuzzy on this part, but I believe it was binutils-2.17 that provided the necessary changes in the linker to use the new functionality in glibc (I believe it was Ken who unearthed that bit). Ultimately, RH could not place an unneeded dependency on a particular version of binutils when you really need files from glibc that were built against that version of binutils, (why they didn't just increment the build number is beyond me, maybe it was a split package at the time or they were dependent on the soname rather than a particular package) so the provides was added in RH/SUSE specs to make the requirements in downstream packages explicitly require this functionality if needed (which probably should be gone so many years later). Your packages never had that split so likely shouldn't add that provides workaround (unless you aim to be able to use RH/SUSE specs without modification, but then why write your own specs?). My suggestion for you to add the above was provided strictly as a workaround to _avoid_ rebuilding LO and keep your existing package (since it takes forever to build). The problem here was always in LO. If you are already going through the trouble of rebuilding LO to account for the other downloads, then you should probably leave the glibc spec alone and remove the rtld requirement from your LO spec(s) so that it uses just your package names and versions (no need to litter the RPM DB with additional provides data). I might be oversimplifying things a bit here, I haven't seen your spec for LO, and it could be some automated thing that I'm unaware of, but that's what I was trying to guide you to discover on your own in my earlier message - precisely why I told you to "provide it" rather than the above verbatim for that matter - which I actually wound up removing from my first message as I though it too much hand-holding. Make you work for it, just a little, and you'll remember for life. :-) Does that make more sense? And that's not to say that what you've done will not work. In fact, it should have made your existing LO rpm installable without any rebuild or need to force it to install, and will clearly meet the requirements for your new rpm if you've still not modified the dependencies. All that said, LFS and BLFS is about learning, but only to a certain point (it has to be usable as well). There is nothing inherently wrong with the above workaround other than it most likely being unnecessary (and a bit unclean IMO) -- clearly RedHat and SUSE, who should be the experts, think it's fine -- but I wanted to take the time to make sure that you understand that the original error was not in your decision to omit the provides in your glibc spec file, but the depends lines in LO's spec. BTW, would you mind sharing both? It might be helpful for somebody else later on and will most definitely answer my remaining question about "some automated thing" above. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , knowledge, explanations and solution
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 0680 004002e8 004002e8 02e8 > 2**3 > 3 .gnu.hash 0050 00400968 00400968 0968 > 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
Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , knowledge, explanations and solution
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 hash 2 .hash 0680 004002e8 004002e8 02e8 2**3 3 .gnu.hash 0050 00400968 00400968 0968 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
Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , libraries questions
On Mon, Aug 26, 2019 at 09:58:18PM +0200, Pierre Labastie via blfs-dev wrote: > Still find 75 by grepping 'saved ' (with a space after, otherwise there are > false positive compiled filenames) > Yes, I typo'd ' saved ' in my earlier post. > A lot of of fonts, but several other packages, and specially 2 jar files. > > Pierre I'd done a 'by the book' build earlier, to measure it, and after grepping that and then using awk on both to print the sixth field, here's a diff (i.e. - only in my build, + only in the full book build) : --- /tmp/downloads.ken 2019-08-26 22:06:04.561505552 +0100 +++ /tmp/downloads.book 2019-08-26 22:06:18.213781355 +0100 @@ -1,33 +1,68 @@ './libabw-0.1.2.tar.xz' +'./commons-logging-1.2-src.tar.gz' +'./beeca87be45ec87d241ddd0e1bad80c1-bsh-2.0b6-src.zip' './libcdr-0.1.5.tar.xz' -'./48d647fbd8ef8889e5a7f422c1bfda94-clucene-core-2.3.3.4.tar.gz' './libcmis-0.5.2.tar.xz' './CoinMP-1.7.6.tgz' './cppunit-1.14.0.tar.gz' './libe-book-0.1.3.tar.xz' './libepubgen-0.1.1.tar.xz' './libetonyek-0.1.9.tar.xz' +'./Firebird-3.0.0.32483-0.tar.bz2' './libfreehand-0.1.2.tar.xz' +'./17410483b5b5f267aa18b7e00b65e6e0-hsqldb_1_8_0.zip' './hunspell-1.7.0.tar.gz' './5ade6ae2a99bc1e9e57031ca88d36dad-hyphen-2.8.8.tar.gz' +'./ba2930200c9f019c2d93a8c88c651a0f-flow-engine-0.9.4.zip' +'./d8bd5eed178db6e2b18eeed243f85aa8-flute-1.1.6.zip' +'./eeb2c7ddf0d302fba4bfc6e97eac9624-libbase-1.1.6.zip' +'./3bdf40c0d199af31923e900d082ca2dd-libfonts-1.1.6.zip' +'./3404ab6b1792ae5f16bbd603bd1e1d03-libformula-1.1.7.zip' +'./db60e4fde8dd6d6807523deb71ee34dc-liblayout-0.2.10.zip' +'./97b2d4dba862397f446b217e2b623e71-libloader-1.1.6.zip' +'./8ce2fcd72becf06c41f7201d15373ed9-librepository-1.1.6.zip' +'./f94d9870737518e3b597f9265f4e9803-libserializer-1.1.6.zip' +'./ace6ab49184e329db254e454a010f56d-libxml-1.1.7.zip' +'./39bb3fcea1514f1369fcfc87542390fd-sacjava-1.3.zip' './libexttextcat-3.4.5.tar.xz' './language-subtag-registry-2019-04-03.tar.bz2' './liblangtag-0.6.2.tar.bz2' './libnumbertext-1.0.5.tar.xz' +'./ltm-1.0.zip' './xmlsec1-1.2.28.tar.gz' './26b3e95ddf3d9c077c480ea45874b3b8-lp_solve_5.5.tar.gz' './a233181e03d3c307668b4c722d881661-mariadb_client-2.0.0-src.tar.gz' './mdds-1.4.3.tar.bz2' +'./368f114c078f94214a308a74c7e991bc-crosextrafonts-20130214.tar.gz' +'./c74b7223abe75949b4af367942d96c7a-crosextrafonts-carlito-20130920.tar.gz' +'./33e1e61fab06a547851ed308b4ffef42-dejavu-fonts-ttf-2.37.zip' +'./1725634df4bb3dcb1b2c91a6175f8789-GentiumBasic_1102.zip' +'./liberation-narrow-fonts-ttf-1.07.6.tar.gz' +'./liberation-fonts-ttf-2.00.4.tar.gz' +'./e7a384790b13c29113e22e596ade9687-LinLibertineG-20120116.zip' +'./907d6e99f241876695c19ff3db0b8923-source-code-pro-2.030R-ro-1.050R-it.tar.gz' +'./edc4d741888bc0d38e32dbaa17149596-source-sans-pro-2.010R-ro-1.065R-it.tar.gz' +'./source-serif-pro-3.000R.tar.gz' +'./EmojiOneColor-SVGinOT-1.3.tar.gz' +'./noto-fonts-20171024.tar.gz' +'./culmus-0.131.tar.gz' +'./libre-hebrew-1.0.tar.gz' +'./alef-1.001.tar.gz' +'./Amiri-0.111.zip' +'./ttf-kacst_2.01+mry.tar.gz' +'./ReemKufi-0.7.zip' +'./Scheherazade-2.100.zip' './libmspub-0.1.4.tar.xz' './libmwaw-0.3.15.tar.xz' './a8c2c5b8f09e7ede322d5c602ff6a4b6-mythes-1.2.4.tar.gz' './libodfgen-0.1.6.tar.bz2' -'./openldap-2.4.45.tgz' './liborcus-0.14.1.tar.gz' './libpagemaker-0.0.4.tar.xz' './pdfium-3794.tar.bz2' './libqxp-0.0.2.tar.xz' './librevenge-0.0.4.tar.bz2' +'./798b2ffdc8bcfe7bca2cf92b62caf685-rhino1_5R5.zip' +'./35c94d2df8893241173de1d16b6034c0-swingExSrc.zip' './libstaroffice-0.0.6.tar.xz' './0168229624cfac409e766913506961a8-ucpp-1.3.2.tar.gz' './libvisio-0.1.6.tar.xz' @@ -36,3 +71,5 @@ './libwps-0.4.10.tar.xz' './libzmf-0.0.2.tar.xz' './884ed41809687c3e168fc7c19b16585149ff058eca79acbf3ee784f6630704cc-opens___.ttf' +'./odfvalidator-1.2.0-incubating-SNAPSHOT-jar-with-dependencies-971c54fd38a968f5860014b44301872706f9e540.jar' +'./8249374c274932a21846fa7629c2aa9b-officeotron-0.7.4-master.jar' In that java is presumably bytecode, yes, shipped rather than locally compiled. ĸ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
Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , libraries questions
Ken Moffat via blfs-dev wrote: On Mon, Aug 26, 2019 at 02:41:19PM -0400, Jean-Marc Pigeon via blfs-dev wrote: On 08/26/2019 02:23 PM, Ken Moffat via blfs-dev wrote: On Mon, Aug 26, 2019 at 02:05:07PM -0400, Jean-Marc Pigeon via blfs-dev wrote: thanks for all your comments... Ken comment about using 38 external parts instead of 77 is having wide implications. - You can have a decent libreoffice, without java,clucene and openldap You misunderstood - I didn't build system clucene and openldap, so it downloaded its own. Right! (Damned!) I really misunderstood.. (shame on me) By any luck, do you have the list of your 38 parts downloaded near by? And could you share it on the mailing list...? Sure. I've just grepped for ' saved ' in the log, it follows at the end. This is a verbose build but I think the downloads produce this information even in non-verbose builds. As I think I said in the past, for verbose builds make verbose=true build-nocheck I think it could be very interesting!. If Pierre and me have around 70 parts, and you have around 40, this means either you are providing the other 30 to libreoffice with your build process (or you disable them at configure level). Yes, disabled at configure level (java, fonts) --without-java\ --without-system-dicts \ --disable-dconf \ -disable-gtk -enable-gtk3 \ --disable-firebird-sdbc \ --disable-odk \ --disable-postgresql-sdbc \ and --without-fonts Thanks ken. 2019-08-18 20:58:48 (2.19 MB/s) - './libabw-0.1.2.tar.xz' saved [318400/318400] 2019-08-18 20:58:49 (2.26 MB/s) - './libcdr-0.1.5.tar.xz' saved [612252/612252] 2019-08-18 20:58:50 (1.53 MB/s) - './48d647fbd8ef8889e5a7f422c1bfda94-clucene-core-2.3.3.4.tar.gz' saved [2241498/2241498] 2019-08-18 20:58:51 (1.58 MB/s) - './libcmis-0.5.2.tar.xz' saved [484404/484404] 2019-08-18 20:58:57 (1.77 MB/s) - './CoinMP-1.7.6.tgz' saved [10343849/10343849] 2019-08-18 20:58:58 (2.14 MB/s) - './cppunit-1.14.0.tar.gz' saved [959716/959716] 2019-08-18 20:58:58 (2.03 MB/s) - './libe-book-0.1.3.tar.xz' saved [416268/416268] 2019-08-18 20:58:59 (2.00 MB/s) - './libepubgen-0.1.1.tar.xz' saved [324380/324380] 2019-08-18 20:59:00 (2.05 MB/s) - './libetonyek-0.1.9.tar.xz' saved [1477064/1477064] 2019-08-18 20:59:00 (2.25 MB/s) - './libfreehand-0.1.2.tar.xz' saved [516132/516132] 2019-08-18 20:59:01 (1.90 MB/s) - './hunspell-1.7.0.tar.gz' saved [938142/938142] 2019-08-18 20:59:01 (2.01 MB/s) - './5ade6ae2a99bc1e9e57031ca88d36dad-hyphen-2.8.8.tar.gz' saved [638369/638369] 2019-08-18 20:59:02 (1.73 MB/s) - './libexttextcat-3.4.5.tar.xz' saved [1041268/1041268] 2019-08-18 20:59:02 (2.37 MB/s) - './language-subtag-registry-2019-04-03.tar.bz2' saved [75120/75120] 2019-08-18 20:59:03 (1.84 MB/s) - './liblangtag-0.6.2.tar.bz2' saved [766080/766080] 2019-08-18 20:59:03 (2.05 MB/s) - './libnumbertext-1.0.5.tar.xz' saved [281640/281640] 2019-08-18 20:59:05 (1.74 MB/s) - './xmlsec1-1.2.28.tar.gz' saved [1995599/1995599] 2019-08-18 20:59:05 (1.73 MB/s) - './26b3e95ddf3d9c077c480ea45874b3b8-lp_solve_5.5.tar.gz' saved [769268/769268] 2019-08-18 20:59:07 (1.63 MB/s) - './a233181e03d3c307668b4c722d881661-mariadb_client-2.0.0-src.tar.gz' saved [1923436/1923436] 2019-08-18 20:59:07 (1.57 MB/s) - './mdds-1.4.3.tar.bz2' saved [334515/334515] 2019-08-18 20:59:08 (1.49 MB/s) - './libmspub-0.1.4.tar.xz' saved [377472/377472] 2019-08-18 20:59:09 (1.81 MB/s) - './libmwaw-0.3.15.tar.xz' saved [1289744/1289744] 2019-08-18 20:59:13 (1.33 MB/s) - './a8c2c5b8f09e7ede322d5c602ff6a4b6-mythes-1.2.4.tar.gz' saved [4910303/4910303] 2019-08-18 20:59:13 (1.49 MB/s) - './libodfgen-0.1.6.tar.bz2' saved [446705/446705] 2019-08-18 20:59:17 (1.79 MB/s) - './openldap-2.4.45.tgz' saved [5672845/5672845] 2019-08-18 20:59:18 (1.68 MB/s) - './liborcus-0.14.1.tar.gz' saved [2454001/2454001] 2019-08-18 20:59:19 (1.56 MB/s) - './libpagemaker-0.0.4.tar.xz' saved [306496/306496] 2019-08-18 20:59:23 (1.72 MB/s) - './pdfium-3794.tar.bz2' saved [7123074/7123074] 2019-08-18 20:59:23 (1.93 MB/s) - './libqxp-0.0.2.tar.xz' saved [341760/341760] 2019-08-18 20:59:24 (1.82 MB/s) - './librevenge-0.0.4.tar.bz2' saved [529833/529833] 2019-08-18 20:59:24 (1.54 MB/s) - './libstaroffice-0.0.6.tar.xz' saved [706324/706324] 2019-08-18 20:59:25 (1.60 MB/s) - './0168229624cfac409e766913506961a8-ucpp-1.3.2.tar.gz' saved [96939/96939] 2019-08-18 20:59:25 (2.17 MB/s) - './libvisio-0.1.6.tar.xz' saved [676396/676396] 2019-08-18 20:59:26 (1.98 MB/s) - './libwpd-0.10.3.tar.xz' saved [534712/534712] 2019-08-18 20:59:26 (1.62 MB/s) - './libwpg-0.3.3.tar.xz' saved [328664/328664] 2019-08-18 20:59:27 (1.23 MB/s) - './libwps-0.4.10.tar.xz' saved [695448/695448] 2019-08-18 20:59:28 (1.40 MB/s) - './libzmf-0.0.2.tar.xz' saved [320952/320952] 2019-08-18 20:59:28 (1.38 MB/s) -
Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , libraries questions
Jean-Marc Pigeon via blfs-dev wrote: On 08/26/2019 09:23 AM, Pierre Labastie via blfs-dev wrote: Jean-Marc Pigeon via blfs-dev wrote: Hello guys (Ken, DJ and Pierre), Thanks to have bring your "pint of brain juice". On 08/26/2019 01:50 AM, Pierre Labastie via blfs-dev wrote: On 25/08/2019 21:49, Jean-Marc Pigeon via blfs-dev wrote: Hello guys (and girls). I need your wisdom... Let's share a pint of brain juice. Here's the drill. context: - LFS-9.0rc (linux 5.2.8, glibc-2.30, gcc-9.2.0) - I am able to build libreoffice-6.3.0.4 with all bells and whistles (lets assume I didn't really goofed with the book directives). I am using zypper + rpm as my own packages management toolkit and rpm say: Error: Failed dependencies: rtld(GNU_HASH) is needed by libreoffice-6.3.0.4-1.53.249.ok_9.0.x86_64 rtld is the run time linker of glibc (the loader of .so libraries). It is certainly installed on your system, otherwise nothing could run (unless you have built everything statically). So, for some reason, it seems that glibc, or part of glibc, is not known to rpm (I do not know much about rpm) on your system. But in that case, it is amazing that you haven't seen that before. Could it be that you have taken an rpm spec file from some distro, and that you have omitted to remove some dep when editing it? About the drill, keep in mind, - the all smash (the >800 packages, glibc included) are recompiled every time. this means discrepancies between glibc and compiled binaries seems to me hardly plausible. - The book directives are used within the "specs file" (build and install sequences), trying my best not to diverge from book directives (using book patches, configure paramaters, etc.) Please see the rpm specs file as MY shell/tool to build LFS+BLFS again and again. - In the building sequences the only package with this rtld report is libreoffice. - libreoffice (as fare I can say) components, once installed, are nicely working. - I am not building statically and not using libtools. - May be I was not specific enough in my original email, RTLD detection show up in the RPM last building phase (the summary phase, saying, here is the list of libraries needed when you will install packages) and (obviously) it become a problem when RPM is used to install the libroffice package Ken is proposing the problem is RPM itself, in such case, as libreoffice is a rather an heavy package, the build is, may be, going over a limit of some kind. I am building the BLFS book within a 30 Gig tmpfs partition (to have speed), may be I am short about something. I have the feeling that going over a threshold of some kind will make RPM to crash/give up in more brutal way. However I'll try my best to prove Ken proposal. My worry (Hoping to be paranoiac) and this concern the book: - When rpm is assembling all files (binaries, scripts, conf, scripts) to do packaging, it scan all added files tracking what is needed (ex: python, shell (zsh,...), shared libraries, etc.) and report it in the summary. This means RPM is detecting something "unexpected". - Libreoffice Book directives are such, that 77 components are added/downloaded within external/tarballs directory, this between the configure phase and the build phase. (please could you confirm this fact from your side). We (the book) have no real control/say about those components (version, contents, function). - It can not be excluded, there a real binary (trojan, virus,...) included within the downloaded files. And this binary show up on RPM scanning phase. Obviously libreoffice, in such case, is fully functional. - That why, I am trying to track down the origin of the RTLD, because if we have an embedded binary "expecting" a usual/common/old glibc to be fully operational, then RPM would have this behaviour. - Please correct me if wrong, but current book directives have no provision to detect such situation. - So fare, I am not successful to track down the issue to a single file, even worth, the "trouble" seems to be in every libreoffice program. Do we agree?, libreoffice is the perfect candidate to be "adjusted" to carry nasty functionality? So guys, please tell me the rtld problem is an obvious/plain one and I am just a crazy paranoid. Hmm, you might not be successful in finding some answer from this list, since I think almost nobody is familiar enough with rpm for telling for sure yes or no... You are certainly the best expert of rpm around. And Ken might be the second. Pierre, you focus far too much on rpm. OK, let's put it another way: rpm finds something, but it is hard to analyze what it is without knowing rpm, and what it does... :) The age/size of the universe is computed via 5 means (from the top of my memory, super-nova, Cepheid, infra-red background noise, etc..), each value is just a random value, what is important/meaningful is the fact those values are in the same range and
Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , libraries questions
On Mon, Aug 26, 2019 at 02:41:19PM -0400, Jean-Marc Pigeon via blfs-dev wrote: > On 08/26/2019 02:23 PM, Ken Moffat via blfs-dev wrote: > > On Mon, Aug 26, 2019 at 02:05:07PM -0400, Jean-Marc Pigeon via blfs-dev > > wrote: > > > > > > thanks for all your comments... > > > Ken comment about using 38 external parts instead of 77 > > > is having wide implications. > > > - You can have a decent libreoffice, without java,clucene and openldap > > > > You misunderstood - I didn't build system clucene and openldap, so > > it downloaded its own. > > > > Right! (Damned!) I really misunderstood.. (shame on me) > > By any luck, do you have the list of your 38 parts downloaded near by? > And could you share it on the mailing list...? Sure. I've just grepped for ' saved ' in the log, it follows at the end. This is a verbose build but I think the downloads produce this information even in non-verbose builds. As I think I said in the past, for verbose builds make verbose=true build-nocheck > I think it could be very interesting!. > If Pierre and me have around 70 parts, and you have around 40, > this means either you are providing the other 30 to libreoffice > with your build process (or you disable them at configure level). > Yes, disabled at configure level (java, fonts) --without-java\ --without-system-dicts \ --disable-dconf \ -disable-gtk -enable-gtk3 \ --disable-firebird-sdbc \ --disable-odk \ --disable-postgresql-sdbc \ and --without-fonts > Thanks ken. > 2019-08-18 20:58:48 (2.19 MB/s) - './libabw-0.1.2.tar.xz' saved [318400/318400] 2019-08-18 20:58:49 (2.26 MB/s) - './libcdr-0.1.5.tar.xz' saved [612252/612252] 2019-08-18 20:58:50 (1.53 MB/s) - './48d647fbd8ef8889e5a7f422c1bfda94-clucene-core-2.3.3.4.tar.gz' saved [2241498/2241498] 2019-08-18 20:58:51 (1.58 MB/s) - './libcmis-0.5.2.tar.xz' saved [484404/484404] 2019-08-18 20:58:57 (1.77 MB/s) - './CoinMP-1.7.6.tgz' saved [10343849/10343849] 2019-08-18 20:58:58 (2.14 MB/s) - './cppunit-1.14.0.tar.gz' saved [959716/959716] 2019-08-18 20:58:58 (2.03 MB/s) - './libe-book-0.1.3.tar.xz' saved [416268/416268] 2019-08-18 20:58:59 (2.00 MB/s) - './libepubgen-0.1.1.tar.xz' saved [324380/324380] 2019-08-18 20:59:00 (2.05 MB/s) - './libetonyek-0.1.9.tar.xz' saved [1477064/1477064] 2019-08-18 20:59:00 (2.25 MB/s) - './libfreehand-0.1.2.tar.xz' saved [516132/516132] 2019-08-18 20:59:01 (1.90 MB/s) - './hunspell-1.7.0.tar.gz' saved [938142/938142] 2019-08-18 20:59:01 (2.01 MB/s) - './5ade6ae2a99bc1e9e57031ca88d36dad-hyphen-2.8.8.tar.gz' saved [638369/638369] 2019-08-18 20:59:02 (1.73 MB/s) - './libexttextcat-3.4.5.tar.xz' saved [1041268/1041268] 2019-08-18 20:59:02 (2.37 MB/s) - './language-subtag-registry-2019-04-03.tar.bz2' saved [75120/75120] 2019-08-18 20:59:03 (1.84 MB/s) - './liblangtag-0.6.2.tar.bz2' saved [766080/766080] 2019-08-18 20:59:03 (2.05 MB/s) - './libnumbertext-1.0.5.tar.xz' saved [281640/281640] 2019-08-18 20:59:05 (1.74 MB/s) - './xmlsec1-1.2.28.tar.gz' saved [1995599/1995599] 2019-08-18 20:59:05 (1.73 MB/s) - './26b3e95ddf3d9c077c480ea45874b3b8-lp_solve_5.5.tar.gz' saved [769268/769268] 2019-08-18 20:59:07 (1.63 MB/s) - './a233181e03d3c307668b4c722d881661-mariadb_client-2.0.0-src.tar.gz' saved [1923436/1923436] 2019-08-18 20:59:07 (1.57 MB/s) - './mdds-1.4.3.tar.bz2' saved [334515/334515] 2019-08-18 20:59:08 (1.49 MB/s) - './libmspub-0.1.4.tar.xz' saved [377472/377472] 2019-08-18 20:59:09 (1.81 MB/s) - './libmwaw-0.3.15.tar.xz' saved [1289744/1289744] 2019-08-18 20:59:13 (1.33 MB/s) - './a8c2c5b8f09e7ede322d5c602ff6a4b6-mythes-1.2.4.tar.gz' saved [4910303/4910303] 2019-08-18 20:59:13 (1.49 MB/s) - './libodfgen-0.1.6.tar.bz2' saved [446705/446705] 2019-08-18 20:59:17 (1.79 MB/s) - './openldap-2.4.45.tgz' saved [5672845/5672845] 2019-08-18 20:59:18 (1.68 MB/s) - './liborcus-0.14.1.tar.gz' saved [2454001/2454001] 2019-08-18 20:59:19 (1.56 MB/s) - './libpagemaker-0.0.4.tar.xz' saved [306496/306496] 2019-08-18 20:59:23 (1.72 MB/s) - './pdfium-3794.tar.bz2' saved [7123074/7123074] 2019-08-18 20:59:23 (1.93 MB/s) - './libqxp-0.0.2.tar.xz' saved [341760/341760] 2019-08-18 20:59:24 (1.82 MB/s) - './librevenge-0.0.4.tar.bz2' saved [529833/529833] 2019-08-18 20:59:24 (1.54 MB/s) - './libstaroffice-0.0.6.tar.xz' saved [706324/706324] 2019-08-18 20:59:25 (1.60 MB/s) - './0168229624cfac409e766913506961a8-ucpp-1.3.2.tar.gz' saved [96939/96939] 2019-08-18 20:59:25 (2.17 MB/s) - './libvisio-0.1.6.tar.xz' saved [676396/676396] 2019-08-18 20:59:26 (1.98 MB/s) - './libwpd-0.10.3.tar.xz' saved [534712/534712] 2019-08-18 20:59:26 (1.62 MB/s) - './libwpg-0.3.3.tar.xz' saved [328664/328664] 2019-08-18 20:59:27 (1.23 MB/s) - './libwps-0.4.10.tar.xz' saved [695448/695448] 2019-08-18 20:59:28 (1.40 MB/s) - './libzmf-0.0.2.tar.xz' saved [320952/320952] 2019-08-18 20:59:28 (1.38 MB/s) -
Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , libraries questions
On 08/26/2019 02:23 PM, Ken Moffat via blfs-dev wrote: On Mon, Aug 26, 2019 at 02:05:07PM -0400, Jean-Marc Pigeon via blfs-dev wrote: thanks for all your comments... Ken comment about using 38 external parts instead of 77 is having wide implications. - You can have a decent libreoffice, without java,clucene and openldap You misunderstood - I didn't build system clucene and openldap, so it downloaded its own. Right! (Damned!) I really misunderstood.. (shame on me) By any luck, do you have the list of your 38 parts downloaded near by? And could you share it on the mailing list...? I think it could be very interesting!. If Pierre and me have around 70 parts, and you have around 40, this means either you are providing the other 30 to libreoffice with your build process (or you disable them at configure level). Thanks ken. -- 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
Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , libraries questions
On Mon, Aug 26, 2019 at 02:05:07PM -0400, Jean-Marc Pigeon via blfs-dev wrote: > > thanks for all your comments... > Ken comment about using 38 external parts instead of 77 > is having wide implications. > - You can have a decent libreoffice, without java,clucene and openldap You misunderstood - I didn't build system clucene and openldap, so it downloaded its own. ĸ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
Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , libraries questions
On 08/26/2019 01:24 PM, dueff...@uwe-dueffert.de wrote: Hi, On Mon, 26 Aug 2019, Jean-Marc Pigeon via blfs-dev wrote: My worry (Hoping to be paranoiac) and this concern the book: - Libreoffice Book directives are such, that 77 components are added/downloaded within external/tarballs directory, this between the configure phase and the build phase. (please could you confirm this fact from your side). We (the book) have no real control/say about those components (version, contents, function). Depending on which part of that worries you most, there might be an easy solution. I do not like that behavior of packages to download arbitrary stuff during build either. My main concern is not that I don't actually know every packages function, but that it is neither useful to download the same set of tarballs a second time at all (for building a second time or on a second machine, especially with limited network access) nor even having to think about the risk of getting something else downloaded the next time. Therefore, for packages like libreoffice (and ISTR apache-ant), I let the build process download its stuff once, integrate only those downloads into an otherwise untouched source folder and repackage and keep this extended package including what it would download rather than the original. So my libreoffice-6.3.0.4++.tar.xz (352MB) has a fetch.log and 77 archives/fonts in its external/tarballs and builds from that do not download anything... I agree 110% with you, this must be the way to do it. (even at book level?) I was to lazy to do it right now, focused I was on this nasty problem (expecting to do it when I will be sure about all needed "external" parts). thanks for all your comments... Ken comment about using 38 external parts instead of 77 is having wide implications. - You can have a decent libreoffice, without java,clucene and openldap (which could be very good enough for my needs). - At the beginning, I build libreoffice without JAVA and I am pretty sure the RTLD problem didn't show up then. (At that time I was focused on having all the "recommended option" included in build). Thanks for the "brain juice" guys Working on 9.0, rebuilding again ;) I'll come back to summarize finding and share knowledge. -- 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
Re: [blfs-dev] elogind and polkit
On Mon, Aug 26, 2019 at 05:41:15PM +0200, Armin K. via blfs-dev wrote:
>
> You seem to be missing one important piece of software in this
> discussion, and that's the one and only device manager, the (E)Udev.
> (E)Udev is responsible for "tagging" a device that can be accessed
> through a seat that is managed by (E)logind.
>
> What I'd suggest for you Ken, is to verify the existence of the
> following (E)Udev rules on your system:
>
> https://github.com/systemd/systemd/blob/master/src/login/70-uaccess.rules.m4
>
the only match for 'input' is
# joysticks
SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="?*", TAG+="uaccess"
But according to
https://unix.stackexchange.com/questions/467382/udev-uaccess-and-hid
Access is granted and revoked to open file descriptors, instead of
the device node.
And there is a link to
https://dvdhrm.wordpress.com/2013/08/25/sane-session-switching/
> https://github.com/systemd/systemd/blob/master/src/login/71-seat.rules.in
>
This looks more hopeful
SUBSYSTEM=="input", KERNEL=="input*", TAG+="seat"
I guess that should be what controls this.
> https://github.com/systemd/systemd/blob/master/src/login/73-seat-late.rules.m4
>
And that rules file exists.
> Your (E)udev needs to be built with ACL support, as the access to the
> tagged nodes is granted through access controls. You can verify if your
> user has correct access on the nodes with "getfacl /dev/input/event0"
> for example.
>
> This way, no old-fashined group membership is required for audio, video,
> cdrom, input, etc groups - if you have a local seat you have access to
> these nodes, and they are granted using access controls by udev itself.
>
On my systems with elogind, nothing -
getfacl: Removing leading '/' from absolute path names
# file: dev/input/event0
# owner: root
# group: input
user::rw-
group::rw-
other::---
And after the noise when changing to a different tty I did set the
following in my kernels:
CONFIG_TMPFS_POSIX_ACL=y
which also enabled
CONFIG_TMPFS_XATTR=y
The log from my build of eudev has no mention of acl or ACL.
> Kind regards.
Thanks. I'm convinced there is probably something simple and
trivial missing. Will look at the google results for
elogind seat access not working
Hmm, the many pages turned out to be far fewer as I dug down.
https://github.com/elogind/elogind/issues/61
Running X on tty1 with myself in the input group ind switching to
tty2 to run loginctl shows
SESSION UID USER SEAT TTY
c1 1000 ken seat0 tty1
c2 1000 ken seat0 tty2
2 sessions listed.
Hmm, following on from that I looked at the linked
/etc/pam.d/system-auth:
# This file is part of elogind.
auth sufficient pam_unix.so nullok try_first_pass
account required pam_nologin.so
account sufficient pam_unix.so
password sufficient pam_unix.so nullok sha512 shadow try_first_pass try_authtok
-session optional pam_loginuid.so
-session optional pam_elogind.so
session sufficient pam_unix.so
I'm not quite sure why the two optional lines there start with '-'
(it's a file, not a diff).
My own is (hopefully) the same as in BLFS ?, without any mention of
pam_elogind.so which is instead in /etc/pam.d/elogind-user
# Begin /etc/pam.d/system-auth
auth requiredpam_unix.so
# End /etc/pam.d/system-auth
and
# Begin /etc/pam.d/elogind-user
account requiredpam_access.so
account include system-account
session requiredpam_env.so
session requiredpam_limits.so
session requiredpam_unix.so
session requiredpam_loginuid.so
session optionalpam_keyinit.so force revoke
session optionalpam_elogind.so
auth requiredpam_deny.so
password requiredpam_deny.so
# End /etc/pam.d/elogind-user
ĸ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
Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , libraries questions
Hi, On Mon, 26 Aug 2019, Jean-Marc Pigeon via blfs-dev wrote: My worry (Hoping to be paranoiac) and this concern the book: - Libreoffice Book directives are such, that 77 components are added/downloaded within external/tarballs directory, this between the configure phase and the build phase. (please could you confirm this fact from your side). We (the book) have no real control/say about those components (version, contents, function). Depending on which part of that worries you most, there might be an easy solution. I do not like that behavior of packages to download arbitrary stuff during build either. My main concern is not that I don't actually know every packages function, but that it is neither useful to download the same set of tarballs a second time at all (for building a second time or on a second machine, especially with limited network access) nor even having to think about the risk of getting something else downloaded the next time. Therefore, for packages like libreoffice (and ISTR apache-ant), I let the build process download its stuff once, integrate only those downloads into an otherwise untouched source folder and repackage and keep this extended package including what it would download rather than the original. So my libreoffice-6.3.0.4++.tar.xz (352MB) has a fetch.log and 77 archives/fonts in its external/tarballs and builds from that do not download anything... Uwe -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , libraries questions
On Mon, Aug 26, 2019 at 12:11:59PM -0400, Jean-Marc Pigeon via blfs-dev wrote: > On 08/26/2019 09:23 AM, Pierre Labastie via blfs-dev wrote: > > Jean-Marc Pigeon via blfs-dev wrote: > > > Hello guys (Ken, DJ and Pierre), > > > > > > Thanks to have bring your "pint of brain juice". > > > Just a few brief comments, neither of which diretly address your rtld problem. > > > > > > Ken is proposing the problem is RPM itself, in such case, as libreoffice > > > is a rather an heavy package, the build is, may be, going over a limit > > > of some kind. > > > I am building the BLFS book within a 30 Gig tmpfs partition > > > (to have speed), may be I am short about something. I have the feeling > > > that going over a threshold of some kind will make RPM to crash/give up > > > in more brutal way. However I'll try my best to prove Ken proposal. > > > For 30 Gig tmpfs you must have a very large amount of RAM. Is it ECC ? If not, in other circumstances I would be tempted to run memtest after problems. In this case, the way the google results seem to be clustered around rpm and (usually) openoffice rather than libreoffice suggest a flipped or failing memory bit is less liekly to be the cause. > > Hmm, you might not be successful in finding some answer from > > this list, since I think almost nobody is familiar enough with rpm > > for telling for sure yes or no... You are certainly the best expert > > of rpm around. And Ken might be the second. Not me, guv. I can usually read enough of a specfile to have soem idea of what is going on, and for building a new or updated package that gives me trouble, that is all I need. The details internal to rpm are generally not something I know about. Support might be a better list for rpm problems, but this one seems so uncommon (the google matches were all very old) that I doubt there will be much benefit in asking there. > Hmmm, keep in mind, we are working on the bleeding edge... > we have glibc-2.30 (a brand new one) and very last libreoffice, if something > is embedded in a forgotten addon (build with a previous > glibc), it could show up only now and may be not seen in > few days/weeks (we are the early birds here). True, but the 'code' is generally compiled. If a compiled binary was included, it would cause breakages when people built on different systems. According to https://bodhi.fedoraproject.org/updates/?packages=libreoffice fedora released 6.3.0.4 to fc31 17 days ago (tooltip of the 'stable' mark in 'status' says "The package has been released to the stable repository". > OK, very good. > you count via "wget" occurrence , I count via "ls -1", > my direct result was 80 and I subtracted the 3 coming from book > directives. same range (77 <-> 75, close enough in our context). > > IMHO, this value (77|75) is, and by far, way too high > (we can not say: all components are build from scratch). > Looking at my own build (no fonts, no java, omitting system clucene, system openldap) I have about 38 packages downloaded. Actually, the last one _is_ a font, opens___.ttf. Fonts don't get built from source, all the other items do (well, some of them might just install some python). > libreoffice compromise, not much result...but this one... > > https://www.linuxquestions.org/questions/linux-software-2/libreoffice-6-and-opengl-rendering-problem-4175652226/ > > ;--- > 04-16-2019, 07:58 AM > [...] > Please note, I'm not saying Libreoffice is compromised. I'm saying that > possibly the whole ecosystem is (not everywhere, not every project) and that > Libreoffice seems like one more thing that has taken a turn away from > reliability. It's not about attributing malice or bad design, I'm sure that > (speaking very broadly) it's a little of both. Libreoffice might just be > using a library that has its direction/reliability compromised. That > wouldn't be their fault any more than it's mine for trying to use > Libreoffice. > ;- > I too occasionally see libreoffice heading offscreen, but much less often with recent versions. ĸ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
Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , libraries questions
On 08/26/2019 09:23 AM, Pierre Labastie via blfs-dev wrote: Jean-Marc Pigeon via blfs-dev wrote: Hello guys (Ken, DJ and Pierre), Thanks to have bring your "pint of brain juice". On 08/26/2019 01:50 AM, Pierre Labastie via blfs-dev wrote: On 25/08/2019 21:49, Jean-Marc Pigeon via blfs-dev wrote: Hello guys (and girls). I need your wisdom... Let's share a pint of brain juice. Here's the drill. context: - LFS-9.0rc (linux 5.2.8, glibc-2.30, gcc-9.2.0) - I am able to build libreoffice-6.3.0.4 with all bells and whistles (lets assume I didn't really goofed with the book directives). I am using zypper + rpm as my own packages management toolkit and rpm say: Error: Failed dependencies: rtld(GNU_HASH) is needed by libreoffice-6.3.0.4-1.53.249.ok_9.0.x86_64 rtld is the run time linker of glibc (the loader of .so libraries). It is certainly installed on your system, otherwise nothing could run (unless you have built everything statically). So, for some reason, it seems that glibc, or part of glibc, is not known to rpm (I do not know much about rpm) on your system. But in that case, it is amazing that you haven't seen that before. Could it be that you have taken an rpm spec file from some distro, and that you have omitted to remove some dep when editing it? About the drill, keep in mind, - the all smash (the >800 packages, glibc included) are recompiled every time. this means discrepancies between glibc and compiled binaries seems to me hardly plausible. - The book directives are used within the "specs file" (build and install sequences), trying my best not to diverge from book directives (using book patches, configure paramaters, etc.) Please see the rpm specs file as MY shell/tool to build LFS+BLFS again and again. - In the building sequences the only package with this rtld report is libreoffice. - libreoffice (as fare I can say) components, once installed, are nicely working. - I am not building statically and not using libtools. - May be I was not specific enough in my original email, RTLD detection show up in the RPM last building phase (the summary phase, saying, here is the list of libraries needed when you will install packages) and (obviously) it become a problem when RPM is used to install the libroffice package Ken is proposing the problem is RPM itself, in such case, as libreoffice is a rather an heavy package, the build is, may be, going over a limit of some kind. I am building the BLFS book within a 30 Gig tmpfs partition (to have speed), may be I am short about something. I have the feeling that going over a threshold of some kind will make RPM to crash/give up in more brutal way. However I'll try my best to prove Ken proposal. My worry (Hoping to be paranoiac) and this concern the book: - When rpm is assembling all files (binaries, scripts, conf, scripts) to do packaging, it scan all added files tracking what is needed (ex: python, shell (zsh,...), shared libraries, etc.) and report it in the summary. This means RPM is detecting something "unexpected". - Libreoffice Book directives are such, that 77 components are added/downloaded within external/tarballs directory, this between the configure phase and the build phase. (please could you confirm this fact from your side). We (the book) have no real control/say about those components (version, contents, function). - It can not be excluded, there a real binary (trojan, virus,...) included within the downloaded files. And this binary show up on RPM scanning phase. Obviously libreoffice, in such case, is fully functional. - That why, I am trying to track down the origin of the RTLD, because if we have an embedded binary "expecting" a usual/common/old glibc to be fully operational, then RPM would have this behaviour. - Please correct me if wrong, but current book directives have no provision to detect such situation. - So fare, I am not successful to track down the issue to a single file, even worth, the "trouble" seems to be in every libreoffice program. Do we agree?, libreoffice is the perfect candidate to be "adjusted" to carry nasty functionality? So guys, please tell me the rtld problem is an obvious/plain one and I am just a crazy paranoid. Hmm, you might not be successful in finding some answer from this list, since I think almost nobody is familiar enough with rpm for telling for sure yes or no... You are certainly the best expert of rpm around. And Ken might be the second. Pierre, you focus far too much on rpm. :) The age/size of the universe is computed via 5 means (from the top of my memory, super-nova, Cepheid, infra-red background noise, etc..), each value is just a random value, what is important/meaningful is the fact those values are in the same range and converging. So, jmp, using RPM, is saying "by the way I am worry we have strange problem with libreoffice binaries, library may be corrupted". This is a bold affirmation, is
Re: [blfs-dev] elogind and polkit
Armin K. via blfs-dev wrote: On 25. 8. 2019. 19:38, Bruce Dubbs via blfs-dev wrote: On 8/25/19 12:18 PM, Pierre Labastie via blfs-dev wrote: [snip] /dev/input/xxx. Actually, I don't think polkit is involved for accessing those: it is the whole purpose of dbus to provide access to hardware devices for normal users. That's my biggest problem wit dbus. According the the website: "D-Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication, D-Bus helps coordinate process lifecycle; it makes it simple and reliable to code a "single instance" application or daemon, and to launch applications and daemons on demand when their services are needed." But why do they need to combine interprocess communication with "launch applications and daemons"? IMO, this is the systemd disease. It just makes things more complicated. -- Bruce Hi, You seem to be missing one important piece of software in this discussion, and that's the one and only device manager, the (E)Udev. (E)Udev is responsible for "tagging" a device that can be accessed through a seat that is managed by (E)logind. What I'd suggest for you Ken, is to verify the existence of the following (E)Udev rules on your system: https://github.com/systemd/systemd/blob/master/src/login/70-uaccess.rules.m4 https://github.com/systemd/systemd/blob/master/src/login/71-seat.rules.in https://github.com/systemd/systemd/blob/master/src/login/73-seat-late.rules.m4 Those files are installed by elogind (with slight modifications, I think), in /lib/udev/rules.d. Your (E)udev needs to be built with ACL support, as the access to the tagged nodes is granted through access controls. You can verify if your user has correct access on the nodes with "getfacl /dev/input/event0" for example. Actually, for me, I am presently running X with functional mouse and keyboard, I am not in the wheel group, and getfacl /dev/input/event0 returns: --- getfacl: Removing leading '/' from absolute path names # file: dev/input/event0 # owner: root # group: input user::rw- group::rw- other::--- -- That is, no ACL... That's a difference with: - $getfacl /dev/dri/card0 getfacl: Removing leading '/' from absolute path names # file: dev/dri/card0 # owner: root # group: video user::rw- user:pierre:rw- group::rw- mask::rw- other::--- - This way, no old-fashined group membership is required for audio, video, cdrom, input, etc groups - if you have a local seat you have access to these nodes, and they are granted using access controls by udev itself. Kind regards. Not sure about the exact mechanism, but I agree with the fact that those memberships are not needed anymore. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , libraries questions
On August 26, 2019 7:31:54 AM CDT, Jean-Marc Pigeon via blfs-dev wrote: >Hello guys (Ken, DJ and Pierre), > >Thanks to have bring your "pint of brain juice". > >On 08/26/2019 01:50 AM, Pierre Labastie via blfs-dev wrote: >> On 25/08/2019 21:49, Jean-Marc Pigeon via blfs-dev wrote: >>> Hello guys (and girls). >>> >>> I need your wisdom... Let's share a pint of brain juice. >>> Here's the drill. >>> >>> context: >>> - LFS-9.0rc (linux 5.2.8, glibc-2.30, gcc-9.2.0) >>> - I am able to build libreoffice-6.3.0.4 with all >>>bells and whistles >>> (lets assume I didn't really goofed with the book directives). >>> >>> I am using zypper + rpm as my own packages management toolkit >>> and rpm say: >>> >>> Error: Failed dependencies: >>> rtld(GNU_HASH) is needed by >libreoffice-6.3.0.4-1.53.249.ok_9.0.x86_64 >>> >> >> rtld is the run time linker of glibc (the loader of .so libraries). >It is >> certainly installed on your system, otherwise nothing could run >(unless you >> have built everything statically). So, for some reason, it seems that >glibc, >> or part of glibc, is not known to rpm (I do not know much about rpm) >on your >> system. But in that case, it is amazing that you haven't seen that >before. >> Could it be that you have taken an rpm spec file from some distro, >and that >> you have omitted to remove some dep when editing it? > >About the drill, keep in mind, >- the all smash (the >800 packages, glibc included) are > recompiled every time. > this means discrepancies between glibc and compiled binaries > seems to me hardly plausible. >- The book directives are used within the "specs file" (build and > install sequences), trying my best not to diverge from book directives > (using book patches, configure paramaters, etc.) Please see the > rpm specs file as MY shell/tool to build LFS+BLFS again and again. >- In the building sequences the only package with this rtld report > is libreoffice. >- libreoffice (as fare I can say) components, once installed, are > nicely working. >- I am not building statically and not using libtools. > >- May be I was not specific enough in my original email, RTLD detection > show up in the RPM last building phase (the summary phase, saying, > here is the list of libraries needed when you will install packages) > and (obviously) it become a problem when RPM is used to install > the libroffice package > > >My worry (Hoping to be paranoiac) and this concern the book: > >- When rpm is assembling all files (binaries, scripts, conf, > scripts) to do packaging, it scan all added files tracking > what is needed (ex: python, shell (zsh,...), shared libraries, etc.) > and report it in the summary. > This means RPM is detecting something "unexpected". > Possibly, it it is configured to find a separate rtld instead of a glibc package. Doesn't really change the answer above. >- Libreoffice Book directives are such, that 77 components are > added/downloaded within external/tarballs directory, this > between the configure phase and the build phase. > (please could you confirm this fact from your side). > We (the book) have no real control/say about those components > (version, contents, function). > >- It can not be excluded, there a real binary (trojan, virus,...) > included within the downloaded files. And this binary show > up on RPM scanning phase. Obviously libreoffice, in such case, > is fully functional. > >- That why, I am trying to track down the origin of the RTLD, >because if we have an embedded binary "expecting" a >usual/common/old glibc to be fully operational, then >RPM would have this behaviour. That provides is in current Suse glibc rpms. I didn't check others (though should've I suppose). > > - Please correct me if wrong, but current book directives >have no provision to detect such situation. > > - So fare, I am not successful to track down the issue to >a single file, even worth, the "trouble" seems to be in every >libreoffice program. > >Do we agree?, libreoffice is the perfect candidate to be >"adjusted" to carry nasty functionality? > >So guys, please tell me the rtld problem is an obvious/plain one >and I am just a crazy paranoid. It didn't just magically show up, something requested it. I suspect that this is a shipped spec, however. Again, this doesn't change the necessary fix. Grep through the entire source tree after the build, see if you can find that string. If so, create a patch and a patch with the patch in it for the LO source (and commands to apply during the build). --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 8/26/19 10:41 AM, Armin K. via blfs-dev wrote: On 25. 8. 2019. 19:38, Bruce Dubbs via blfs-dev wrote: On 8/25/19 12:18 PM, Pierre Labastie via blfs-dev wrote: [snip] /dev/input/xxx. Actually, I don't think polkit is involved for accessing those: it is the whole purpose of dbus to provide access to hardware devices for normal users. That's my biggest problem wit dbus. According the the website: "D-Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication, D-Bus helps coordinate process lifecycle; it makes it simple and reliable to code a "single instance" application or daemon, and to launch applications and daemons on demand when their services are needed." But why do they need to combine interprocess communication with "launch applications and daemons"? IMO, this is the systemd disease. It just makes things more complicated. -- Bruce Hi, You seem to be missing one important piece of software in this discussion, and that's the one and only device manager, the (E)Udev. (E)Udev is responsible for "tagging" a device that can be accessed through a seat that is managed by (E)logind. What I'd suggest for you Ken, is to verify the existence of the following (E)Udev rules on your system: https://github.com/systemd/systemd/blob/master/src/login/70-uaccess.rules.m4 https://github.com/systemd/systemd/blob/master/src/login/71-seat.rules.in https://github.com/systemd/systemd/blob/master/src/login/73-seat-late.rules.m4 Your (E)udev needs to be built with ACL support, as the access to the tagged nodes is granted through access controls. You can verify if your user has correct access on the nodes with "getfacl /dev/input/event0" for example. This way, no old-fashined group membership is required for audio, video, cdrom, input, etc groups - if you have a local seat you have access to these nodes, and they are granted using access controls by udev itself. Hi Armin. Long time eudev and acl are built in LFS. http://www.linuxfromscratch.org/lfs/view/development/chapter06/eudev.html -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 25. 8. 2019. 19:38, Bruce Dubbs via blfs-dev wrote: On 8/25/19 12:18 PM, Pierre Labastie via blfs-dev wrote: [snip] /dev/input/xxx. Actually, I don't think polkit is involved for accessing those: it is the whole purpose of dbus to provide access to hardware devices for normal users. That's my biggest problem wit dbus. According the the website: "D-Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication, D-Bus helps coordinate process lifecycle; it makes it simple and reliable to code a "single instance" application or daemon, and to launch applications and daemons on demand when their services are needed." But why do they need to combine interprocess communication with "launch applications and daemons"? IMO, this is the systemd disease. It just makes things more complicated. -- Bruce Hi, You seem to be missing one important piece of software in this discussion, and that's the one and only device manager, the (E)Udev. (E)Udev is responsible for "tagging" a device that can be accessed through a seat that is managed by (E)logind. What I'd suggest for you Ken, is to verify the existence of the following (E)Udev rules on your system: https://github.com/systemd/systemd/blob/master/src/login/70-uaccess.rules.m4 https://github.com/systemd/systemd/blob/master/src/login/71-seat.rules.in https://github.com/systemd/systemd/blob/master/src/login/73-seat-late.rules.m4 Your (E)udev needs to be built with ACL support, as the access to the tagged nodes is granted through access controls. You can verify if your user has correct access on the nodes with "getfacl /dev/input/event0" for example. This way, no old-fashined group membership is required for audio, video, cdrom, input, etc groups - if you have a local seat you have access to these nodes, and they are granted using access controls by udev itself. Kind regards. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , libraries questions
Jean-Marc Pigeon via blfs-dev wrote: Hello guys (Ken, DJ and Pierre), Thanks to have bring your "pint of brain juice". On 08/26/2019 01:50 AM, Pierre Labastie via blfs-dev wrote: On 25/08/2019 21:49, Jean-Marc Pigeon via blfs-dev wrote: Hello guys (and girls). I need your wisdom... Let's share a pint of brain juice. Here's the drill. context: - LFS-9.0rc (linux 5.2.8, glibc-2.30, gcc-9.2.0) - I am able to build libreoffice-6.3.0.4 with all bells and whistles (lets assume I didn't really goofed with the book directives). I am using zypper + rpm as my own packages management toolkit and rpm say: Error: Failed dependencies: rtld(GNU_HASH) is needed by libreoffice-6.3.0.4-1.53.249.ok_9.0.x86_64 rtld is the run time linker of glibc (the loader of .so libraries). It is certainly installed on your system, otherwise nothing could run (unless you have built everything statically). So, for some reason, it seems that glibc, or part of glibc, is not known to rpm (I do not know much about rpm) on your system. But in that case, it is amazing that you haven't seen that before. Could it be that you have taken an rpm spec file from some distro, and that you have omitted to remove some dep when editing it? About the drill, keep in mind, - the all smash (the >800 packages, glibc included) are recompiled every time. this means discrepancies between glibc and compiled binaries seems to me hardly plausible. - The book directives are used within the "specs file" (build and install sequences), trying my best not to diverge from book directives (using book patches, configure paramaters, etc.) Please see the rpm specs file as MY shell/tool to build LFS+BLFS again and again. - In the building sequences the only package with this rtld report is libreoffice. - libreoffice (as fare I can say) components, once installed, are nicely working. - I am not building statically and not using libtools. - May be I was not specific enough in my original email, RTLD detection show up in the RPM last building phase (the summary phase, saying, here is the list of libraries needed when you will install packages) and (obviously) it become a problem when RPM is used to install the libroffice package Ken is proposing the problem is RPM itself, in such case, as libreoffice is a rather an heavy package, the build is, may be, going over a limit of some kind. I am building the BLFS book within a 30 Gig tmpfs partition (to have speed), may be I am short about something. I have the feeling that going over a threshold of some kind will make RPM to crash/give up in more brutal way. However I'll try my best to prove Ken proposal. My worry (Hoping to be paranoiac) and this concern the book: - When rpm is assembling all files (binaries, scripts, conf, scripts) to do packaging, it scan all added files tracking what is needed (ex: python, shell (zsh,...), shared libraries, etc.) and report it in the summary. This means RPM is detecting something "unexpected". - Libreoffice Book directives are such, that 77 components are added/downloaded within external/tarballs directory, this between the configure phase and the build phase. (please could you confirm this fact from your side). We (the book) have no real control/say about those components (version, contents, function). - It can not be excluded, there a real binary (trojan, virus,...) included within the downloaded files. And this binary show up on RPM scanning phase. Obviously libreoffice, in such case, is fully functional. - That why, I am trying to track down the origin of the RTLD, because if we have an embedded binary "expecting" a usual/common/old glibc to be fully operational, then RPM would have this behaviour. - Please correct me if wrong, but current book directives have no provision to detect such situation. - So fare, I am not successful to track down the issue to a single file, even worth, the "trouble" seems to be in every libreoffice program. Do we agree?, libreoffice is the perfect candidate to be "adjusted" to carry nasty functionality? So guys, please tell me the rtld problem is an obvious/plain one and I am just a crazy paranoid. Hmm, you might not be successful in finding some answer from this list, since I think almost nobody is familiar enough with rpm for telling for sure yes or no... You are certainly the best expert of rpm around. And Ken might be the second. What I can add is the if not stripping binaries, sure 30Gb is not enough for building everything up to libreoffice. As you said, the book cannot detect whether some of the packages downloaded during libreoffice build are goofed. But I doubt it would be possible that nobody else notice: the files are downloaded and their shasum is checked, so an attacker would have to provide a file with the same shasum to be able to add something of his own, or to change the libreoffice tarball itself, but if that person is able to do
Re: [blfs-dev] LibreOffice-6.3.0 , Version 2019-08-22, rtld(GNU_HASH) , libraries questions
Hello guys (Ken, DJ and Pierre), Thanks to have bring your "pint of brain juice". On 08/26/2019 01:50 AM, Pierre Labastie via blfs-dev wrote: On 25/08/2019 21:49, Jean-Marc Pigeon via blfs-dev wrote: Hello guys (and girls). I need your wisdom... Let's share a pint of brain juice. Here's the drill. context: - LFS-9.0rc (linux 5.2.8, glibc-2.30, gcc-9.2.0) - I am able to build libreoffice-6.3.0.4 with all bells and whistles (lets assume I didn't really goofed with the book directives). I am using zypper + rpm as my own packages management toolkit and rpm say: Error: Failed dependencies: rtld(GNU_HASH) is needed by libreoffice-6.3.0.4-1.53.249.ok_9.0.x86_64 rtld is the run time linker of glibc (the loader of .so libraries). It is certainly installed on your system, otherwise nothing could run (unless you have built everything statically). So, for some reason, it seems that glibc, or part of glibc, is not known to rpm (I do not know much about rpm) on your system. But in that case, it is amazing that you haven't seen that before. Could it be that you have taken an rpm spec file from some distro, and that you have omitted to remove some dep when editing it? About the drill, keep in mind, - the all smash (the >800 packages, glibc included) are recompiled every time. this means discrepancies between glibc and compiled binaries seems to me hardly plausible. - The book directives are used within the "specs file" (build and install sequences), trying my best not to diverge from book directives (using book patches, configure paramaters, etc.) Please see the rpm specs file as MY shell/tool to build LFS+BLFS again and again. - In the building sequences the only package with this rtld report is libreoffice. - libreoffice (as fare I can say) components, once installed, are nicely working. - I am not building statically and not using libtools. - May be I was not specific enough in my original email, RTLD detection show up in the RPM last building phase (the summary phase, saying, here is the list of libraries needed when you will install packages) and (obviously) it become a problem when RPM is used to install the libroffice package Ken is proposing the problem is RPM itself, in such case, as libreoffice is a rather an heavy package, the build is, may be, going over a limit of some kind. I am building the BLFS book within a 30 Gig tmpfs partition (to have speed), may be I am short about something. I have the feeling that going over a threshold of some kind will make RPM to crash/give up in more brutal way. However I'll try my best to prove Ken proposal. My worry (Hoping to be paranoiac) and this concern the book: - When rpm is assembling all files (binaries, scripts, conf, scripts) to do packaging, it scan all added files tracking what is needed (ex: python, shell (zsh,...), shared libraries, etc.) and report it in the summary. This means RPM is detecting something "unexpected". - Libreoffice Book directives are such, that 77 components are added/downloaded within external/tarballs directory, this between the configure phase and the build phase. (please could you confirm this fact from your side). We (the book) have no real control/say about those components (version, contents, function). - It can not be excluded, there a real binary (trojan, virus,...) included within the downloaded files. And this binary show up on RPM scanning phase. Obviously libreoffice, in such case, is fully functional. - That why, I am trying to track down the origin of the RTLD, because if we have an embedded binary "expecting" a usual/common/old glibc to be fully operational, then RPM would have this behaviour. - Please correct me if wrong, but current book directives have no provision to detect such situation. - So fare, I am not successful to track down the issue to a single file, even worth, the "trouble" seems to be in every libreoffice program. Do we agree?, libreoffice is the perfect candidate to be "adjusted" to carry nasty functionality? So guys, please tell me the rtld problem is an obvious/plain one and I am just a crazy paranoid. -- 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
