On Dec 17, 2008, at 8:28 PM, Joe Ciccone wrote:
William Harrington wrote:
gcc now defaults to 32 bit at least! The other issue is when using
this on a ppc64 machine, that config.guess will return
powerpc64-unknown-linux-gnu, which will cause problems, that's why
the
uname_hack has entered the world of my build.
Here's another thought. You could build a multilib cross-compiler for
the final system binutils and gcc with the host of
powerpc-unknown-linux-gnu and the target of powerpc64-unknown-linux-
gnu.
Then use a config.site to force everything to powerpc-unknown-linux-
gnu
instead of the uname hack. That would probably make upgrading the
kernel
loads easier. Or even maybe just building a completely 32bit userspace
and build a 64bit binutils, gcc into /opt specifically for compiling
the
kernel.
Just some food for thought.
Nah, it is food for nurture! I'm hungry! I'm eating thoughts now.
Thanks Joe. The current system I'm building with is 32 bit user space
all together with the 64 enabled compiler in /opt. The idea which I
thought was being talked about was to just build a 32 bit user space
altogether with a compiler with a toolchain that could build 64 bit
binaries and could be tested as working.
I already did the /opt suggestion last month:
The subject was: PPC64 with 32 bit user space build comments
back in November on the 16th.
Either way, I think it is best to build multilib up to gcc then go 32
bit after that. ./configure can take a target of powerpc and the
uname_hack is easy as heck. When the user finishes the system, there
is the foundation to build 64 bit with no issues. All that is changed
is that the compiler will build 32 bit by default, however, the host
system detected is powerpc64. Good stuff! Kind of exciting, too.
Really I think the main question is... if we go to this idea with
sparc64 and ppc64, is a whole new book needed? if that is the case,
then just using the uname_hack would be best I think.
First off, I need to get this build completed and working properly
with CLFS SVN.
-William
-William
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
