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

Facts:
0) I see no building alarm or errors during the
   building process (build is successful)
1) Among the >800 packages, libreoffice is the only one
   to be flagged by RPM.
2) If I bypass the RPM advice and install libreoffice,
   all components (impress, calc , draw, etc..) are
   working properly (as far I can tell). This means
   not using RPM (just using book directives), the
   potential trouble would never show up.
3) Within my whole building process I try to get rid of
   libtool libraries (removing all .la file. Meanwhile
   I do not believe it could be related)
4) It is first time I am compiling libreoffice, so
   I can't say if such problem was already within 8.4.
5) Building according book and removing binaries
   (tedious task), seems to indicate all linked binaries
   are requesting rtld (so all libreoffice binaries need rtld !).

My "friend" Google:
According my understanding of Google, this kind of problem
is caused by the libc library not in pace (lib version)
with package. This seems very unlikely, in our context
libreoffice is compiled with the running glibc.


Questions:
1) Could someone give us some enlightenment  about
   what is rtld (GNU_HASH) exactly?
2) I noticed libreoffice come with its own set of luggage
   (some as esoteric as
   ba2930200c9f019c2d93a8c88c651a0f-flow-engine-0.9.4.zip)
   but I'll be very surprised libreoffice loading/using its own
   precompiled glibc, agreed?
   However, I have the very strong feeling the problem
   is caused by the "zillion" of external/outdated
   components downloaded by the build process.
2) Could the problem be within the glibc library I/We
   have build  (a glibc building sequence weakness?)
3) I am very curious to find+understand from where the
   RTLD story is coming from. I was not good enough
   to extract something useful by doing a binary objdump
   to track down the origin.
   Could someone propose a search path?


Thanks for your kind help and your wisdom.

--
seen "Linux from scratch" and looking for ISO files
www.osukiss.org

Attachment: 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

Reply via email to