tools only installation?

tools only installation?

[Vincent Fortier]

Hi,

Currently maintaining a SynoCommunity development package with a set
of various tools including compilers.  One thing I'd really much like
to add is ldd, as everything being cross-compiled, having a native ldd
would be helpful to check shared libraries relationships directly from
its installed destination.

So I've been playing with glibc to cross-compile it, which now works.
Although I now have two remaining issues:
1. I can't find a way to install only the set of glibc tools, without
the entire library or any include files?  Focus being in particular to
ldd.
2. Presumably in lack of a solution for item 1, when invoking glibc
build after my other set of tools already built in planning to
generate a resulting package, glibc ends-up colliding with the already
installed gmp.h include file, coming from binutils who required gmp as
dependency.  I'm presuming I should not build glibc first as
everything else will be bound to that newer version of glibc instead
of the one provided by the Synology toolchain.

github PR: https://github.com/SynoCommunity/spksrc/pull/5824

Help or pointers would be really much appreciated.

Thnx in advance.

Vincent Fortier

Re: tools only installation?

[Adhemerval Zanella Netto]

On 30/07/23 08:58, Vincent Fortier via Libc-help wrote:
> Hi,
> 
> Currently maintaining a SynoCommunity development package with a set
> of various tools including compilers.  One thing I'd really much like
> to add is ldd, as everything being cross-compiled, having a native ldd
> would be helpful to check shared libraries relationships directly from
> its installed destination.
> 
> So I've been playing with glibc to cross-compile it, which now works.
> Although I now have two remaining issues:
> 1. I can't find a way to install only the set of glibc tools, without
> the entire library or any include files?  Focus being in particular to
> ldd.
> 2. Presumably in lack of a solution for item 1, when invoking glibc
> build after my other set of tools already built in planning to
> generate a resulting package, glibc ends-up colliding with the already
> installed gmp.h include file, coming from binutils who required gmp as
> dependency.  I'm presuming I should not build glibc first as
> everything else will be bound to that newer version of glibc instead
> of the one provided by the Synology toolchain.
> 
> github PR: https://github.com/SynoCommunity/spksrc/pull/5824
> 
> Help or pointers would be really much appreciated.

The ldd is essentially a script that issues the loader, you can also issue
this direct:

$ LD_TRACE_LOADED_OBJECTS=1 /lib64/ld-linux-x86-64.so.2 /usr/bin/ls
        linux-vdso.so.1 (0x00007ffd6efaf000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007ff78e8d8000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff78e600000)
        libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007ff78e841000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff78e948000)

The only limitation is it does not resolve the interpreter, so you
must issues the one define in the ELF file. A normal cross-compile 
installation would have it.

Also glibc uses an internal only gmp.h which is not installed in the system 
so it is not clear to me what you referring for the gmp.h collision. The
glibc provides a handy script to build cross-compile toolchain 
(build-many-glibcs.py), so it should be a matter to target the proper
architecture along with the expected versions (the build-many-glibcs.py
does not provide a way to define specific version, but you can easily
setup manually).

Another option would be use a different tool instead of ldd, as the
suggested libtree cited on the PR. I have also created a similar
tool [1] which should works slight better (it supports more architectures,
support more ld.so.cache version and parses it directly instead of
parsing ld.so.conf, it supports the new hwcap selection added on 
recent glibc).

It is different than ldd because it parses the ELF file and mimic the loader,
which is different than actually starting the loading process (as ldd does).

[1] https://github.com/zatrazz/rldd