Re: powerpc64 gcc compiler ...
On Wed, Mar 31, 2004 at 08:12:36AM +0200, Matthias Klose wrote:
> Sven Luther writes:
> > First, i found that this gcc-3.4 package in experimental wasn't yet
> > built on powerpc, which i did. It did output lot of FAILs in the tests
> > later on, but i am not sure this is worrying or not.
>
> Please have a look at http://gcc.gnu.org/ml/gcc-testresults/ and compare.
Ok. Mmm, i seem to have more stuff, including something which seems
really broken. You can have a look at the full build log at :
http://people.debian.org:~luther/gcc-3.4-powerpc.log.gz
> > It builds simple binaries without problems. But it didn't build the
> > biarch toolchain, so it was of no use for me.
> >
> > After a bit of investigation, i found out that :
> >
> > --target=powerpc64-linux --with-cpu=default32
>
> both s390 and sparc build the 32bit compiler and patch gcc/config.gcc
> to include the 64bit specific Makefile chunks. At least this installs
> things in a <arch>-linux subdirectory, not <arch>-linux64. I don't
> know if there other changes building this way. Look at the -biarch
> patches in debian/patches.
Huh, notice that this is gcc-3.4, which i am told support powerpc biarch
without need for patching. Indeed, if i look at the s390-biarch patch, i
only get :
While if i consult src/gcc/config.c, i find that i already have this :
powerpc64-*-linux*)
tmake_file="rs6000/t-fprules t-slibgcc-elf-ver t-linux rs6000/t-ppccomm rs6000/t-linux64"
So, it should be ok for powerpc64. That said, for non-64 powerpc i have :
powerpc-*-linux*)
tmake_file="rs6000/t-fprules rs6000/t-ppcos t-slibgcc-elf-ver t-linux rs6000/t-ppccomm"
So the t-linux64 is clearly missing. Now, i don't know which of the two
cases will be chosen with the above options. The ppc64 guys tell me that
the above is enough in gcc-3.4 to enable ppc32 and ppc64 biarch, and to
make ppc32 the default, so i somehow guess that the first one is chosen,
right ?
> > I don't really know what the plans are for ppc64 support, but i hear
> > that biarch userland is a post sarge issue. Also, i understood that we
> > will not switch over to gcc 3.4 for sarge, which is the reason why it is
> > in experimental currently. Or maybe it would be possible to have gcc 3.4
> > in unstable and later sarge, without it necessarily being the default ?
>
> not one more compiler in sarge. If we want to have 3.4 in sarge, we
> should drop 3.2 first. If 3.4 is released, built for all Debian
> architectures and no regressions found for packages which replace
> their 3.3 counterparts, then lets propose this to debian-release ...
> Upstream development asked/proposed Linux distributions to include a
> libstdc++6 in current releases.
Ok, this doesn mean that you condemn any chance of there being a set of
ppc64 kernels in debian/sarge, which means that some box will be
unsupported. Or do you mean i should use backports, or the gcc 3.3
hammer branch, and have 3.3 support this, which means a possibly more
disruptive situation ? And do some arches not need 3.4 ? What would be
the price of dropping 3.2 first ?
BTW, even if 3.4 goes to unstable and is hold out of sarge by a
hold-RC-bug or something, would this addition of gcc-3.4 not be
transparently added without further impact on the gcc->gcc-3.3 use.
> > What i am trying to do, and what would be nice, would be to have at
> > least ppc64 kernels for the sarge release, since some boxes may need
> > this and will have trouble with 32bit kernels. Don't know if this is
> > realistic, but it seems to me that only gcc support is needed in order
> > to achieve that. I hear that a 64bit procps and module-init-tools will
> > be needed too, and probably a libncurses, which may be a problem, but
> > let's worry about this later.
>
> well, you need a lib64c6-dev as well. Unsure how much prepared the
> glibc sources are and if the glibc maintainers are willing to include
> such packages for sarge.
I doubt they will. And i think a glibc fixup would be something which
would follow a 64bit gcc and kernel. In my understanding, the support
chain goes as follows :
binutils (ok) -> gcc -> kernel -> glibc.
> > Anyway, my question here is if you would consider it reasonable to
> > enable the powerpc biarch toolchain, and have it default to 32bit for
> > gcc 3.4 ? This should cause no problem for ordinary powerpc, but would
> > allow to build ppc64 stuff with the same toolchain. Am i correct with
> > this assumption ? I will try tomorrow to build this, but would it make
> > sense to enable this in the experimental powerpc packages ? And what
> > about the not gcc or cxx compilers ?
>
> Including your patches is ok, enable it by default not, as lib64c6-dev
Why ? What would be the adverse effect of this ? And if we want to have
ppc64 support, how can that be done without enabling ppc64-biarch
support ?
> is missing as a build dependency. To disable the runtime lib64raries
> you do not want add a patch like sparc-config-ml or s390-config-ml.
I have difficulties parsing this.
> At least for gcj you you have to do some extra configury, as it builds
> the gtk based peer classes, for which you don't have dependent
> lib64raries.
At this point, i mainly care about a biarch 64bit gcc to be able to
build the kernel, the rest should come later, and hopefully with the
help of a more competent gcc guy than just plain me. Nobody volunteered
though, it seems, so despite our revered leader interest in ppc64
support, there will be no such thing.
Friendly,
Sven Luther
Reply to: