This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PING]^N Fix ppc64 bootstrap with a -m32 host compiler


> Right, but this isn't happening currently.  Or I confuse what you mean
> with "host" libiberty - libiberty is only build for the host, not for
> the target, no?

Build libiberty is used to link gen*, programs that *run* *during* the
build.

Host libiberty is used to link gcc et al, programs that run *after*
the build, i.e. on the *host* you configured for.

Target libiberty is used to link programs built by the new gcc,
programs that will run on the *target* you configured for.

Consider a canadian - I'm using my linux box to build a gcc.exe that
will run under cygwin and produce m32c images.  $build_cc is linux's
native gcc, which builds gen*, which run on the linux box during the
build.  These have to link with a linux libiberty.  $host_cc is going
to be a linux-x-cygwin cross compiler, so that the resulting gcc.exe
runs on cygwin.  This gcc.exe needs to be linked with a cygwin
libiberty.  When I run that gcc.exe on cygwin, I'll also need an m32c
libiberty for my rom image.

> The problem is that while host and target are ppc64, build is ppc32.

The problem is that in stage2, build is *still* ppc32, but should
build be ppc64 now?  If build is still ppc32, we want 32-bit libiberty
and 32-bit genfoo.  If build is supposed to be ppc64, we want 64-bit
*build* libiberty and 64-bit genfoo.  In either case, we're building a
64-bit gcc.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]