bug#39583: Error with cross-compiling where CCLD is Clang

On Wed, 12 Feb 2020, Jo Shields wrote:

> Hi,
>
> I've been working on a project where we cross-compile for aarch64, on an
> x86_64 host. The compiler we're under orders to use (I have no say here)
> is Clang.
>
> The norm with GCC is for a `triplet-gcc` binary as CC. For Clang,
> cross-compiling is achieved with a `--target=triplet` compiler flag - i.e.
>
> `aarch64-linux-gnu-gcc foo.c`
>
> vs
>
> `clang --target=aarch64-linux-gnu foo.c`
>
> Critically, this applies even for cases where CC is being used as the
> linker (i.e. CCLD=clang). If no `--target` is specified, Clang will use
> the native (x86_64) linker, not the linker specified in LD.
>
> This can be worked around by throwing `-XCClinker --target=triplet` into
> every linker invocation in every makefile, but it would be nice if
> instead, ltmain preserved the `--target` parameter in func_mode_link
> (e.g. the way it does for `--sysroot`)

It is not necessary for Autotools to conform and adapt to this clang 
option.  Instead, developers/users of clang-based cross-compilation 
configurations should arrange so that program files like 
'aarch64-linux-gnu-clang' exist.  This tool naming strategy is for the 
benefit of Autotools and other build scripts and not for the 
compiler's benefit.  It is important to maintain the common 
conventions which have worked sucessfully for many years.

If clang does not have a default cross-compilation target so the 
paths can be created using symbolic links, then 
trivial wrapper scripts/programs can be created so that clang is 
automatically provided with the correct arguments.

Bob
-- 
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt



_______________________________________________
Bug-libtool mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-libtool