toolchain/external: copy libssp.so if SSP is enabled
authorYann Droneaud <ydroneaud@opteya.com>
Fri, 25 Oct 2019 13:42:41 +0000 (15:42 +0200)
committerThomas Petazzoni <thomas.petazzoni@bootlin.com>
Fri, 25 Oct 2019 14:40:07 +0000 (16:40 +0200)
commit971479ed6276782a1768a1b8effec2a34787661c
treea5f612cd9f71b53a973ae564e19defc4ac309b17
parent41f06fa0bbe0b0bfeb72e9c701f77e607505cdd9
toolchain/external: copy libssp.so if SSP is enabled

In Buildroot, the internal toolchain backend uses the SSP support from
the C library, not that of gcc.

Some external toolchains come with SSP suport in gcc, which is
implemented in libssp.so, rather than in the C library.

When a toolchain even has both, it is up to the compiler to decide
whether it will link to libssp or use the support from the C library.

However, in the latter case, a (incorrectly written) package may decide
to explicitly link with libssp.so when it is available (even though the
compiler may have decided otherwise if left by itself). This is the case
for example with sox, which results in runtime failures, such as:

    $ sox
    sox: error while loading shared libraries: libssp.so.0: cannot open
    shared object file: No such file or directory

Even if sox is wrong in doing so, the case for libssp-only toolchains is
still valid, and we must copy it as we copy other libs.

Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
toolchain/toolchain-external/pkg-toolchain-external.mk