Hello, I'm trying to compile for the aarch64 architecture using an external gcc 4.8 toolchain. However I get the following error : >>> toolchain-external-custom Installing to staging directory /usr/bin/install -D -m 0755 /home/jpcartal/Dev/Ssd/buildroot/buildroot-2017.02/N30_test/build/toolchain-external-custom/toolchain-wrapper /home/jpcartal/Dev/Ssd/buildroot/buildroot-2017.02/N30_test/host/usr/bin/toolchain-wrapper aarch64-linux-gcc: error: unrecognized command line option '-mabi=lp64' My understanding is that the mabi=lp64 option is only available on gcc 4.9.x and newer. Is there any solution available to compile for aarch64 architecture with a gcc 4.8.x toolchain ? Thanks for your help.
(In reply to Jean-pierre Cartal from comment #0) You could remove the lp64 line from arch/Config.in.arm, but considering how old gcc 4.8 is compared to aarch64, does it really make sense to use such an old toolchain?
Hi, Thanks for your help. Unfortunately we don't have much choice regarding the toolchain version as it is currently provided by a 3rd party. We might try to use buildroot toolchain since that would indeed solve our issue. Thanks for the tip on where to remove the lp64 option. As a side note, wouldn't it make sense to disable aarch64 compilation with external gcc toolchains older than 4.9.x since it will not work ? Regards.
For custom external toolchains, we simply let the user specify which gcc version the toolchain uses, and check that at the beginning of the build. We don't try to prevent the user from using an unsupported gcc version depending on the selected architecture, and I don't think we want to go down this route. Especially since custom external toolchain quite often use vendor-specific gcc versions that are patched to support additional features/processors, and unnecessarily restricting the set of gcc versions to use would not be very nice. For example, a patched gcc 4.8 could very well support lp64. So I don't think we'll try to solve this problem.
We don't try to prevent the user from using an unsupported gcc version depending on the selected architecture, and I don't think we want to go down this route. So I don't think we'll try to solve this problem.
> We don't try to prevent the user from using an unsupported gcc version > depending on the selected architecture, and I don't think we want to go > down this route. > So I don't think we'll try to solve this problem. Agreed.