GNU bug report logs - #39583
Error with cross-compiling where CCLD is Clang

Previous Next

To reply to this bug, email your comments to 39583 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jo Shields <directhex <at> apebox.org>
To: bug-libtool <at> gnu.org
Subject: Error with cross-compiling where CCLD is Clang
Date: Wed, 12 Feb 2020 16:46:37 -0500

[Message part 1 (text/plain, inline)]

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`)

[signature.asc (application/pgp-signature, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: Jo Shields <directhex <at> apebox.org>
Cc: 39583 <at> debbugs.gnu.org, bug-libtool <at> gnu.org
Subject: Re: bug#39583: Error with cross-compiling where CCLD is Clang
Date: Wed, 12 Feb 2020 16:19:26 -0600 (CST)

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
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.