[Buildroot] Potential lurking issue with host rpaths

[Buildroot] Potential lurking issue with host rpaths

[Yann E. MORIN]

Thomas, Arnout, Peter, All,

Consider the following situation for packages 'bar' and 'libfoo':
  - upstream bar has an optional dependency on libfoo
  - in Buildroot, host-bar does not depend on host-libfoo, because
    we do not need that dependency [0]
  - a third package (whatever, not in the dependency chain of host-bar)
    brings in host-libfoo into the build.

Now, let's look at what happens:

- without PPD
  - libfoo not installed on the host system
    - host-libfoo built before host-bar
      - bar links to libfoo
        - bar has an RPATH for another lib
          => OK
        - bar does not have an RPATH for another lib
          -> check-host-rpath errors out for host-bar
          => OK
    - host-libfoo built after host-bar
      -> bar not linked to libfoo
      => OK

  - libfoo installed on the host system
    - host-libfoo built before host-bar
      - bar links to host-libfoo
        - bar has an RPATH for another lib
          => OK
        - bar does not have an RPATH for another lib
          -> check-host-rpath errors out for host-bar
          => OK
    - host-libfoo built after host-bar
      - bar links to system libfoo
        - bar has an RPATH for another lib
          -> check-host-rpath OK for both host-bar and host-libfoo
          -> error at runtime: bar uses host-libfoo instead of system
             libfoo
          => KO, MISSED
        - bar does not have an RPATH for another lib
          -> check-host-rpath errors out for host-libfoo
          => OK [1]


- with PPD
  - libfoo not installed on the host system
    -> bar never linked to libfoo
    => OK

  - libfoo installed on the host system
    -> bar always linked to system libfoo
      - bar has an RPATH for another lib
        -> check-host-rpath OK for host-bar
        -> error at runtime: bar uses host-libfoo instead of system
           libfoo, *but* only once the final, complete host directory
           has been aggregated
        => KO, MISSED
      - bar does not have an RPATH for another lib
        -> check-host-rpath OK for host-bar
        => OK


So, in either case (PPD or no PPD), we do have an issue with optional
dependencies for host packages...


Now, the questions:
  - are those two issues for real, or did I miss something?
  - is they are real, how can we fix them?


[0] for example host-systemd does not depend on host-libselinux, because
    we only need systemctl, but systemd will always also build nspawn,
    which may link with libselinux if present.

[1] check-host-rpath errors out for host-libfoo instead of host-bar, so
    for the wrong package, but at least it errors out and we can notice
    the issue.


Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Potential lurking issue with host rpaths

[Thomas Petazzoni]

Hello,

On Wed, 25 Dec 2019 16:13:51 +0100
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> - without PPD
>   - libfoo not installed on the host system
>     - host-libfoo built before host-bar
>       - bar links to libfoo
>         - bar has an RPATH for another lib
>           => OK  
>         - bar does not have an RPATH for another lib
>           -> check-host-rpath errors out for host-bar
>           => OK  
>     - host-libfoo built after host-bar
>       -> bar not linked to libfoo
>       => OK  
> 
>   - libfoo installed on the host system
>     - host-libfoo built before host-bar
>       - bar links to host-libfoo
>         - bar has an RPATH for another lib
>           => OK  
>         - bar does not have an RPATH for another lib
>           -> check-host-rpath errors out for host-bar
>           => OK  
>     - host-libfoo built after host-bar
>       - bar links to system libfoo
>         - bar has an RPATH for another lib
>           -> check-host-rpath OK for both host-bar and host-libfoo
>           -> error at runtime: bar uses host-libfoo instead of system  
>              libfoo
>           => KO, MISSED  

True, but I'm not sure what we can do here. The only thing we can do is
to add all the appropriate --disable-<foo> options to make sure host-bar
doesn't link with any optional library that we don't have as a
dependency.

> - with PPD
>   - libfoo not installed on the host system
>     -> bar never linked to libfoo
>     => OK  
> 
>   - libfoo installed on the host system
>     -> bar always linked to system libfoo  
>       - bar has an RPATH for another lib
>         -> check-host-rpath OK for host-bar
>         -> error at runtime: bar uses host-libfoo instead of system  
>            libfoo, *but* only once the final, complete host directory
>            has been aggregated
>         => KO, MISSED  

Absolutely. This is indeed a weird thing with the PPD stuff: during the
build of Buildroot, we are never using what is going to be the final
SDK. I'm not sure what we can do about it though, except as suggested
above, ensures we have as much as possible the appropriate
--disable-<foo>, but obviously this is never going to be perfect: new
optional dependencies are going to be added by upstream, and we will
not notice them.

A (crazy?) idea is perhaps to check against which libraries host
binaries/libraries end up being linked with. They should only be linked
against:

 - Other libraries in HOST_DIR

 - A small reduced set of system libraries, which we could have a
   whitelist (libc, libm, librt, libgcc_s, libatomic, etc.).

If one of our host program links against something else from the host
system, then it is not good, and we should error out. At least this
would allow us to *detect* such issues, and hopefully thanks to that
add the appropriate --disable-<foo> options where needed. The user
would also be clearly notified that there is something not good going
on with one of the host packages.

Other ideas ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com