Bug 1378882

Summary: aarch64-linux-gnu-gcc: compilation fails
Product: [Fedora] Fedora Reporter: Nikos Mavrogiannopoulos <nmavrogi>
Component: cross-gccAssignee: David Howells <dhowells>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dan, dhowells
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-09-23 15:30:26 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Nikos Mavrogiannopoulos 2016-09-23 12:53:05 UTC
How reproducible:
$ cat >c.c <<__EOF
int
main ()
{

  ;
  return 0;
}
__EOF

$ aarch64-linux-gnu-gcc c.c
/usr/bin/aarch64-linux-gnu-ld: cannot find crt1.o: No such file or directory
/usr/bin/aarch64-linux-gnu-ld: cannot find crti.o: No such file or directory
/usr/bin/aarch64-linux-gnu-ld: cannot find -lc
/usr/bin/aarch64-linux-gnu-ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status

Comment 1 David Howells 2016-09-23 15:30:26 UTC
These cross-compilers intentionally do not include C libraries for a number of reasons:

 (1) Not all arches can be used with glibc and not all can use uClibc.  This means that, at minimum, both of these would have to be included in the SRPM and the compiler bootstrapped with one or other, depending on the subarch.

 (2) Not all variants of an arch can use the same C library.  MIPS, for example, has at least 6 variants, each of which would require a different compilation of the library.

 (3) What do we do about arches supported by the upstream compiler and the kernel, but not an upstream C library?

 (4) A kernel (or, at least, the headers therefrom) would need to be included in the SRPM also - but the build of the C library and of the compiler may vary, depending on the contents of the kernel headers.

 (5) There may be other dependencies that would also need to be included in the SRPM.

 (6) If I add a C library, someone will come along wanting C++ support too, ...

The primary motivation is to provide compilers for compiling kernels - which don't need things like C libraries.

Things get very big and complex when C libraries are added to the mix.

Comment 2 Nikos Mavrogiannopoulos 2016-09-26 06:29:31 UTC
Ok, let's make a simpler question. How can one cross-compile with this package? Is it possible at all, or this is a placeholder package?

Comment 4 Dan HorĂ¡k 2016-09-26 06:38:31 UTC
(In reply to Nikos Mavrogiannopoulos from comment #2)
> Ok, let's make a simpler question. How can one cross-compile with this
> package? Is it possible at all, or this is a placeholder package?

You can cross-compile with these compilers, but not regular user-space stuff, kernels, firmwares, etc are possible.

Also one could build the full "cross" stack of tools and libs based on these packages.