[Buildroot] [PATCH] toolchain: create symlink to 'lib' from ARCH_LIB_DIR iso fixed lib32/lib64
Arnout Vandecappelle
arnout at mind.be
Mon Dec 28 22:08:23 UTC 2015
On 21-12-15 14:29, Thomas De Schampheleire wrote:
> Hi Arnout,
>
> Sorry, I completely missed your reply. Thanks for reviewing. See below...
>
> On Mon, Nov 16, 2015 at 10:57 PM, Arnout Vandecappelle <arnout at mind.be> wrote:
>> Hi Thomas,
>>
>> On 19-10-15 11:07, Thomas De Schampheleire wrote:
>>> From: Thomas De Schampheleire <thomas.de.schampheleire at gmail.com>
>>>
>>> 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' (likewise for lib64-fp).
>>>
>>> More generally, for external toolchains, the correct symbolic link is
>>> from (usr/)${ARCH_LIB_DIR} to lib. For internal toolchains, current
>>> toolchains always use either lib32 or lib64.
>>
>> Sorry, it's not OK (yet). The reason we add the lib32 and lib64 symlinks for
>> the internal toolchain as well is because there are some slightly broken
>> packages that expect these directories to exist. With this patch, the symlink is
>> no longer created for some external toolchains, e.g. musl. Unfortunately, I'm
>> not sure which packages are problematic. A quick search through the archives
>> points at libatomic_ops as a candidate.
>
> Did you mean 'external' instead of 'internal' in the second sentence
> of this paragraph?
No, I meant external. But I agree that my explanation wasn't very clear.
>
> For internal toolchains, the lib32 or lib64 symlink is always created,
> with and without this patch. Agreed?
For internal toolchains, things are still OK with your patch.
>
> For external toolchains, if ARCH_LIB_DIR == 'lib', previously symbolic
> links lib32 or lib64 would be created anyhow, but with this patch they
> are not. I guess this is the case you refer to?
Exactly, and for example external musl toolchains are in this situation.
>
>>
>> So I think the solution is to keep on creating the symlink like is done now,
>> and just check if ${ARCH_LIB_DIR} exists for the external toolchains.
>
> You mean to create a lib32/lib64 symlink as before, and additionally a
> link '${ARCH_LIB_DIR} -> lib' in case ARCH_LIB_DIR is different from
> 'lib32' and 'lib64', right?
Yep. Though it probably will make things even uglier.
Regards,
Arnout
>
> Thanks,
> Thomas
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
More information about the buildroot
mailing list