Comment 4 for bug 602743

Hello Andrew,

Thanks for the quick reply!

2010/7/8, Andrew Stubbs <email address hidden>:
> The requirement for backward compatibility assumes that multiarch is an
> extension of single-arch, and you still want to be able to run binaries
> built under the current layout.

OK, I think I now understand correctly. You want to keep multiarch
backward compatible with current system layout. I understood from the
first post that you wanted to implement sysroot configs and be
backward compatible with multiarch (which it is not there yet).

> I'm really not sure what schemes the current --sysroot configuration
> options can support, or what scheme you have in mind, but I'm pretty
> sure it's insufficient.

Insufficient for what? I missed the point here. Sysroot is just a
directory in the system with a layout which could be exported (via NFS
or by other means) to a target/foreign system. It is similar concept
to a chroot, but it is not a chroot.

> I agree that it could be done the way you suggest, using "/opt/arm-
> linux-gnueabi/. Equally, it could be done as "/usr/arm-linux-
> gnueabi/lib". I'm not sure if there are any standards to follow here.

Sure. My suggestion goes into /opt but there might be other places in
the system that it could work too, we should check Debian Policy which
Mr S Langasek knows very well. The triplet bit is a key question to
have a working multiarch environment. So, my suggestion was
sysroot=/opt/$arch_triplet, that would be our directory.

The sysroot directory itself is the home of a new system (should
follow FHS path convention) which waits to be populated. So libs
(./usr/lib/) and headers (./usr/include/), as well as sysroot
compilers and other tools (./bin|./tools|???) should live into the
sysroot, right?

When multiarch was suggested, suggested paths (they really look pretty), were:
  /usr/lib/$triplet_arches (this is the only one drafted within
MultiarchSpec at ubuntu wiki)
  /usr/include/$triplet_arches (this one was drafted at MultiarchCross
at ubuntu wiki, but not taken into consideration)

The paths above, break FHS, hence we have no upstream support and
those were picked up instead (working) cross compiling dirs
(/usr/$triplet/{lib,include,bin} because cross compiling paths polute
/usr with $triplet names (which I never understood). In any way, all
the placement of libraries and headers and done by an ackward hack
called dpkg-cross (over ten years by now, which Mr Watson worked on in
the early days). Current dpkg-cross Debian maintainer, Mr Williams,
not happy to maintain such hack wanted to merge it into Debian dpkg
proper, but Debian dpkg maints did not wanted to take it unless it was
multiarch compliant (the right solution).

After a year of tests and proofs, I have just realized (thanks to Mr
Wookey and Mr Williams) that dpkg-cross can go away very easily and
there is no need to have a complex multiarch design which involves
patching very criptic dpkg core code and deal with dependencies and
build-dependencies for many (all) arches in very insane ways and not
to mention the bloated dpkg database which might slow down dpkg
performance in many ways. How does that work?

Well, if I am correct and if not, please say so. I do believe that
upstream supports and recommends sysroot. Hence, we could
build_from_source and/or bootstrap_from_binaries a chroot like system
which most important bits are headers, libs and dpkg database, as well
as, cross tools. Which are the benefits?

Runtime linker can pick up the right libs by passing --sysroot
$sysroot_dir, so 32/64 bit issues could be worked out.

Cross toolchains, could just use --sysroot $sysroot_dir to cross
compile the code.

Dpkg database and core code stays the same and we do not need to do
intrusive changes in toolchains and (build/run)time dependency
resolvers.

To get a working base of packages into the $sysroot, could be done
today as debootstrap --foreign (or newer multistrap) does. It would be
nice to have filters into Dpkg to remove unneeded stuff. Then software
could get installed into $sysroot as something like: $ dpkg --root
$sysroot --foreign -i <new-package_ver_foreignarch>.deb

To get a new architecture bootstrap from source, you do it in a
similar way, but cross compiling. (I have undocumented partial trivial
code into `buildcross' -- Debian/experimental -- to do that).

I am pretty sure that can work in the cross building case, not sure if
it would work in the cross runtime case (see plugins, config files,
etc...), might be worth to check with Mr Tollef and Mr S Langasek. But
it certainly avoids messing arround with non trivial stuff as dealing
with build/runtime dependencies resolvers, bloat Dpkg database, which
might slow down Dpkg performance, and so on...

> I suggest you say what scheme you'd *really* like, and we'll go away and
> work out if it's feasible (i.e. are there any hidden gotchas, from a
> toolchain perspective).

Great! Sounds like I am managing here or even making my wise become true :-)

I wrote "Multicross sysroot proposal paths (/opt)" (a year ago) at
http://wiki.debian.org/toolchain-multiarch which are the paths I
meant, the figure still has some typos and errors but you'll get the
idea from it (I hope). Just consider "/" as a normal FHS layout and
look under /opt/$sysroot for the FHS stuff I am talking about for
foreign arches.

I would also like to suggest you a nice reading, a paper from HP to
Canonical (or the other way) which explains very nicely multiarch
options, but did not took under consideration the sysroot way I am
proposing here.
  http://multiarch.alioth.debian.org/multiarch-hp-report.pdf

> 1. What directory layout would you like (and maybe a word or two on
> why).

I do believe this should be clear by now.

> 2. Do you plan to have separate toolchains for each architecture, or do
> you plan to use one toolchain with multilibs?

Whatever we agree (as Debian) is fine with me. Personally I would go
for individual cross toolchains for each architecture (armel, mips,
mipsel, sh4, powerpc, ...) and multilibs enabled for variants (like
armel soft, softfp, hardfp variants) as upstream suggests.

> When we know these things, we'll look at how we can support that with
> config options that would be acceptable upstream. The target triplet
> would be an ideal unique identifier, if you intend to use multiple
> toolchains, but any old unique string will do.

Sure. Are you really being serious and listening to me? I am somehow
shocked! :-)

> The goal here is to add a patch to Linaro which enables Ubuntu, but is
> not yet another custom patch we have to carry around. The upstream
> maintainers tend to be a bit finicky, so ideally we'll run it past them
> first and get it approved before we end up stuck with something
> incompatible.

I do not think a patch is needed, only Dpkg filters might be a good
thing to implement. In anyway, it is very smart from your side to have
upstream consideration and not carry on a patch that can be applied
upstream (GNU GCC).

I would also like to call your attention onto being nice to your
upstream distribution and merge general stuff into Debian proper, then
you could add any knobs and tweaks you like as a derivative.

Best wishes,
--
 Héctor Orón

"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."