Hi Jim,
Adding the suggested options reveals something interesting:
attempt to open crt1.o failed attempt to open crti.o failed attempt to open /work/integration/envs/latest/tools/gcc/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/4.9.3/crtbeginT.o succeeded /work/integration/envs/latest/tools/gcc/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/4.9.3/crtbeginT.o
These are the paths used to find the 64-bit libraries, which are just ../lib64 from the 32-bit libraries.
And that's our issue! We've had the brilliant idea of storing toolchains in git repositories (not pointing the finger at anyone :-)) but git doesn't store empty folders. That means the empty libc/usr/lib folder used to construct the 64-bit libraries path using ../lib64 isn't there. It also explains why it was working for the person who pushed the change: he still had the directory coming from the extracted tarball.
Thank you very much for your help.
Regards, Kévin
-----Original Message----- From: Jim Wilson [mailto:jim.wilson@linaro.org] Sent: 15 April 2015 18:50 To: Kevin Petit Cc: linaro-toolchain@lists.linaro.org; Ian Spray; Mark Hambleton; James King Subject: Re: Issue building busybox using aarch64-linux-gnu 2014.11
On Wed, Apr 15, 2015 at 9:51 AM, Kevin Petit Kevin.Petit@arm.com wrote:
It seems none of the built-in library search paths (gcc –print-search-dirs) allow to find crt[1i].o. They seem to be expected in a multiarch location but aren’t (libc/usr/lib64). We’re working around this with a symlink. Is this a bug? Have you seen similar issues?
I downloaded a toolchain from this page. https://www.linaro.org/downloads/
It works fine for a simple example. I don't see anything in the option list that would cause a problem. Busybox could perhaps be setting environment variables to change compiler behaviour, that can cause problems, but it is rare that people set gcc environment variables. That isn't obvious from the bug report. I haven't built busybox in a long time, so I don't know if it is doing anything unusual offhand.
You can debug this yourself a bit by adding a -v option to see the linker option that gcc is running. This should contain explicit paths to the crt1.o and crti.o files. You can check to see if the paths are correct and the files exist. If there environment variables set, they should be in the -v output.
You can also add -Wl,--verbose to get verbose info from the linker. This will show you the linker built-in paths, and what files the linker is trying to open. For my simple testcase I see
attempt to open /home/wilson/Downloads/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/../libc/usr/lib/../lib64/crt1.o succeeded /home/wilson/Downloads/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/../libc/usr/lib/../lib64/crt1.o attempt to open /home/wilson/Downloads/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/../libc/usr/lib/../lib64/crti.o succeeded /home/wilson/Downloads/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/../libc/usr/lib/../lib64/crti.o
In the gcc --print-search-dirs output, at the end, I see
/home/wilson/Downloads/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/../libc/lib/:/home/wilson/Downloads/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/../libc/usr/lib/
These are the paths used to find the 64-bit libraries, which are just ../lib64 from the 32-bit libraries.
Jim
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782