Bug 1378882 - aarch64-linux-gnu-gcc: compilation fails
Summary: aarch64-linux-gnu-gcc: compilation fails
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: cross-gcc
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: David Howells
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-23 12:53 UTC by Nikos Mavrogiannopoulos
Modified: 2016-09-26 10:57 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-23 15:30:26 UTC
Type: Bug


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.