2006/11/8, Jim Heck - Sun Microsystems <Jim.Heck@sun.com>:
Hector,
I'm trying again to build GCC 3.4 as I type. I've been studying your
buildcross script today. I've run into some issues, and I have one or
two questions/observations that you might be able to answer/clarify.
Just to be clear I haven't tried the buildcross script proper yet, but
am using it as a guide to try to manually build the gcc-3.4 toolchain.
Have you take a look to SLIND way ?
In all the mirrors I've looked at, there don't seem to be any usable
lib64gcc1 powerpc libraries under the /debian/pool/main/g/gcc-3.4/
directory like there are under the /debian/pool/main/g/gcc-4.1/
directory. I'm not sure that buildcross script could succeed at line
278 for the powerpc gcc-3.4 toolchain build becuase I don't think such a
file exists.
I have to check this one out. Thanks for telling.
This is important, however, since the gcc-3.4 build fails if the 64 bit
crossed libraries are not installed (I think I have gotten around this
in the past by setting in the environment 'WITHOUT_LANG=biarch') .
Perhaps your script succeeds because the lib64gcc1 library is already
installed from a previous gcc flavor build (like the gcc-4.1 flavor)?
So I went ahead and installed the version of lib64gcc1 from the
/debian/pool/main/g/gcc-4.1/ directory with the other 64 bit libraries:
lib64gcc1_4.1.1-13_powerpc.deb
libc6-ppc64_2.3.6.ds1-7_powerpc.deb
libc6-dev-ppc64_2.3.6.ds1-7_powerpc.deb
I then did a build using the same settings as the buildcross script and
was able to build most of the gcc-3.4 packages. Note that not all the
packages seem to have built. Specifically, there are warnings at the end
of the dpkg-buildpackage log indicating the following libraries were
specified in the control file but not the files list
dpkg-genchanges: warning: package libgcc1-powerpc-cross in control file
but not in files list
dpkg-genchanges: warning: package lib32stdc++6-powerpc-cross in control
file but not in files list
dpkg-genchanges: warning: package libgcc2-powerpc-cross in control file
but not in files list
dpkg-genchanges: warning: package lib64gcc1-powerpc-cross in control
file but not in files list
dpkg-genchanges: warning: package lib64stdc++6-powerpc-cross in control
file but not in files list
The only one that seems to really matter is libgcc1-powerpc-cross, upon
which libstdc++6-powerpc-cross depends. This is the same package I had
problems with in the past building gcc-3.4. I see that you have some
special handling for libgcc1-powerpc-cross in the buildcross script
when making a gcc-3.4 compiler (for instance, you don't try to install
this package for gcc-3.4).
IRC, you can use libgcc1 from gcc-4.0, in testing, that is what they do, gcc-3.4 with libgcc1-4.0.
Do you know of a reason why libgcc1-powerpc-cross is not being built (or
the other packages for that matter)? I note that your sandbox doesn't
have one either.
I did a 'dpkg -c' on a libgcc1-powerpc-cross package and found that the
only file of consequence it contains is libgcc_s.so.1. This is among a
list of files noted as not included in any pakcage at the end of the log
from dpkg-buildpackage (an exerpt below), so the file is built, it is
just not getting into a package.
So at this point, I had a set of packages, but was missing a
libgcc1-powerpc-cross package. I proceeded to install the packages
using dpkg --force-depends -i ... to get around the missing dependency.
I was able to build the 2.4.33 kernel successfully even though I don't
have a libgcc_s.so.1 library in my powerpc compiler path. The resulting
image was able to do a minimal boot on a powerpc based RPXLite DW board.
That is good ! :-)
So in summary, the two issues I uncovered are:
1. The dependence of the gcc-3.4 build on the non-existent
lib64gcc1_3.4.6-4_powerpc.deb crossed library package.
I'll try to see
2. The missing libgcc1-powerpc-cross package from the gcc-3.4
dpkg-buildpackage process that prevents a clean install of the
libstdc++6-powerpc-cross_3.4.6-4_i386.deb package.
Use the one from gcc-4.0
Finally, I still wonder what the compiler does with the kernel headers,
and if there are significant structural changes from the
2.4 kernel
headers to the 2.6 kernel headers that might cause problems when running
a 2.4 kernel. As you suggested, I'll need to try to build using 2.4
headers (though I can't think of a nice clean way to do this without
hacking out the build dependency on the linux-kernel-headers package,
which doesn't exist for 2.4 kernel headers).
I have been told that there is no difference.
If you've read this far thanks!
Thanks to you !