On August 26, 2019 7:31:54 AM CDT, Jean-Marc Pigeon via blfs-dev <[email protected]> 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
