toolchain-external: create symlink ARCH_LIB_DIR->lib
authorThomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Thu, 28 Jan 2016 12:32:46 +0000 (13:32 +0100)
committerThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Mon, 1 Feb 2016 13:20:10 +0000 (14:20 +0100)
commitcef3cd40b7a168f2e1f532f4b621a259f5ace095
treea36517467451b4b7c0f8372a915ace5019a54ea3
parentfe23cb5d00513bbec1c347166db74943869e2196
toolchain-external: create symlink ARCH_LIB_DIR->lib

Currently, following symbolic links are created in both target and
staging directories:
- lib(32|64) --> lib
- usr/lib(32|64) --> lib

The decision for lib32 or lib64 is based on the target architecture
configuration in buildroot (BR2_ARCH_IS_64).

In at least one case this is not correct: when building for a Cavium Octeon
III processor using the toolchain from the Cavium Networks SDK, and
specifying -march=octeon3 in BR2_TARGET_OPTIMIZATION, libraries are expected
in directory 'lib32-fp' rather than 'lib32' (ABI=n32; likewise for
lib64-fp in case of ABI=n64)

More generally the correct symbolic link is from (usr/)${ARCH_LIB_DIR}->lib.
However, feedback from Arnout Vandecappelle is that there are packages that
do depend on the lib32/lib64 symlink, even if ARCH_LIB_DIR is different.
Hence, these links must be kept.

Fix the problem as follows:
- For internal toolchains: no change
- For external toolchains: create a symlink ARCH_LIB_DIR->lib if
  (usr/)ARCH_LIB_DIR does not exist yet.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: "Yann E. Morin" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
toolchain/toolchain-external/toolchain-external.mk