There are now only two blockers for the minimal Emdebian RootFS:
base-passwd (= 3.5.11em1) depends on libgcc1 (>= 1:4.1.1-12) {NOT AVAILABLE}
busybox (= 1:1.1.3-4em1) depends on libgcc1 (>= 1:4.1.1-12) {NOT AVAILABLE}
cdebconf (= 0.115em1) depends on libgcc1 (>= 1:4.1.1-12) {NOT AVAILABLE}
dpkg (= 1.13.25em1) depends on libgcc1 (>= 1:4.1.1-12) {NOT AVAILABLE}
initscripts (= 2.86.ds1-38em1) depends on libgcc1 (>= 1:4.1.1-12) {NOT AVAILABLE}
libpopt0 (= 1.10-3em1) depends on libgcc1 (>= 1:4.1.1-12) {NOT AVAILABLE}
module-init-tools (= 3.3-pre4-2em1) depends on libgcc1 (>= 1:4.1.1-12) {NOT AVAILABLE}
passwd (= 1:4.0.18.1-7em1) depends on libgcc1 (>= 1:4.1.1-12) {NOT AVAILABLE}
sysvinit (= 2.86.ds1-38em1) depends on libgcc1 (>= 1:4.1.1-12) {NOT AVAILABLE}
login (= 1:4.0.18.1-7em1) depends on libpam-modules (>= 0.72-5) {NOT AVAILABLE}
The PAM problem comes down to:
Relocations in generic ELF. dynamic/pam_item.o: could not read symbols: File in wrong format
So far, I've been concentrating on other packages and haven't spent
that much time on pam so this may be a simple error where the pam build
is either selecting the wrong compiler for that object or needs to
avoid trying to execute that object via some addition to ./configure
etc.
The biggest problem is libgcc1.
This is where it gets confusing, so these are the critical points:
1. libgcc1 is part of gcc-4.1 and the current Debian version fails to
build on arm and other Emdebian arches, has RC bugs and is stalling
1,200 packages from entering Debian testing. (This is why the Emdebian
toolchains have not been updated to the version in Debian unstable.)
Therefore, the only libgcc1 worth considering from our perspective is
that from the version of gcc-4.1 currently in Debian testing : 4.1.1-21.
2. The current toolchains necessarily include a libgcc1 binary but that
is created by dpkg-cross : libgcc1-arm-cross_4.1.1-21_all.deb when what
we need is libgcc1_4.1.1-21_arm.deb, only emdebianised to
libgcc1_4.1.1-21em1_arm.deb.
3. The build for libgcc1_4.1.1-21_arm.deb needs to specify:
a) build = amd64 (or i386 or even powerpc)
b) host = arm
c) target = arm
A toolchain build (buildcross) is:
a) build = amd64 (or i386 or even powerpc)
b) host = amd64, i386 or powerpc respectively
c) target = arm
A Debian build (pbuilder etc.) is:
a) build = amd64 (or i386 or even powerpc)
b) host = amd64 (etc.)
c) target = amd64 (etc.)
So this (AFAICT) isn't a true Canadian Cross, it's a (simple?)
cross-build. Just like any other package, gcc is being built on one
arch to run on another and once installed on the other, it is intended
to behave as if it had always been compiled for that arch, i.e. it
would generate code that was native to the arch on which it is
installed, in the above case: arm.
4. After tweaking debian/rules.* in the gcc-4.1 build to set the above
triad, gcc-4.1 fails to build:
build-x86_64-linux-gnu/libiberty/libiberty.a: could not read symbols: File format not recognized
In outward appearance this would appear to be the same problem as pam
and many other cross-builds - the build process needs to be told not to
try to execute certain objects. The problem comes in the sheer size of
gcc and the risk that this could be just the first of many errors
further through the build.
Options:
A. Co-opt the native build libgcc1 from Debian and report this as a bug
in gcc-4.1 in the Debian BTS using the usertag:crossbuild.
B. Attempt to isolate libgcc1 from the gcc-4.1 build so that it is the
only target built in the hope that this will avoid problematic
components of the build that are not actually needed at this time
anyway.
C. Continue working inside the current build to try to fix it - Zumbi
has already indicated that he does not think the Debian sources can be
fixed in this way.
OptionA has the problem that Emdebian could then not be built
(completely) from source.
OptionB may not work, despite a lot of effort.
OptionC could suck in enormous amounts of time considering the amount
of time required to test each change to the gcc build and may still
fail.
With either OptionA or OptionB, Emdebian would be lacking a native
compiler but that isn't such a big problem at this time.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
pgp7X5qavImwx.pgp
Description: PGP signature