Re: [Debian-bootstrap] An apparent need for gcc-<triplet>, cpp-<triplet>, g++-<triplet>, etc.
+++ Marcin Juszkiewicz [2012-07-02 14:39 +0200]:
> W dniu 02.07.2012 13:21, Wookey pisze:
> >> There are gcc-defaults-arm{el,hf}-cross packages in Ubuntu which
> >> take care of symlinks. Going that way was discussed at Emdebian
> >> sprint in February 2011 and everyone agreed.
> >
> > OK. But that was also viewed as an interim arrangement until this
> > multiarch toolchain work was done, so I think we should review this
> > and check we still agree this is the right thing for Debian now.
>
> Even with multiarch toolchain we will need such metapackages. From which
> source package they will be created is other thing.
'need' is a bit strong. It may be the best way to manage multiple
toolchain versions and defaulting but it's perfectly possible to set
things up with these (as we used to).
We are collecting a pile of extra packages needed for making
cross-building and toolchain management nice (cross-gcc-defaults, cross-build-essential,
cross-pkg-config packages and the autoconf/cmake caching currently in
dpkg-cross). It's not yet clear to me whether to have little source
packages for each of these things or a bigger 'cross-support' package
that deals with all this. It's tempting to glob some of it together to
avoid tiny-source-package bloat and for consistency of dependencies,
but I'm not sure if it actually helps or hinders. Maybe it doesn't
matter much...
> >>>> Default Versions of Cross Compilers and Preprocessors
> >>>> -----------------------------------------------------
>
> >> Native gcc is selected by 'gcc' package from gcc-defaults. In
> >> Ubuntu cross gcc is selected same way: gcc-triplet is symlink to
> >> gcc-X.Y-triplet (where X.Y of cross == X.Y of native gcc).
> >
> > OK, so do dependencies ensure this package is always installed so
> > you always end up with a symlink?, or do we have to rely on telling
> > people to install the generic cross-compiler package, not a specific
> > cross-compiler package? It does seem to work on ubuntu, I just don't
> > understand how.
>
> "apt-get install gcc-arm-linux-gnueabihf" is what is suggested to people
> when they want to install cross compiler under Ubuntu. If they want to
> do application development then "apt-get install libc6-dev-armhf-cross"
> is second step as this package is only recommendation (same issue in
> Emdebian).
OK, but once you have cross-build essential then you install that and
it _could_ be responsible for gcc-version defaulting instead of
gcc-<triplet> packages. Does the extra level of indirection help here?
> > How do you switch the symlink if you want to use a different
> > version?
>
> In same way as you select other version of native compiler?
That's not a useful answer :-) How do I do that? I know how to do it
with alternatives. I don't know how to do do it for this special-case.
Now I guess I don't know because I've never felt the need to change
the default native compiler, and hopefully that'll be the same for
cross-tools too. But if no-one ever needed to change then making it
possible to install two at once is a waste of time...
> > What is the advantage of this method over /etc/alternatives?
>
> For long time /etc/alternatives way was broken - all gcc versions had
> same priority so if you installed 4.4 and then 4.3 you ended with 4.3 as
> default. Later I fixed this so version == priority and then support got
> removed.
OK. I'm pretty happy with 'last one installed is the one I want to
default to' actually, because that'll usually be the newest for people
who don't care. But I can live with 'newest is default' too.
> Advantage is that user of distribution has *default* compiler version as
> default. So if you are on 'precise' and install gcc-4.7/cross it does
> not mean that it became default one.
OK. But if I installed 4.7 that was probably because I wanted to use
it... Are you sure this is an actual advantage?
One thing that is a consideration is that multiarch cross-toolchains
will be (even) more closely tied to native versions so synchronising
the defaulting in this way may make sense.
> Cross compiler in Debian derived systems looks like was used mostly for
> compiling kernels not applications (libc-dev is only recommendation not
> dependency).
Because you _can_ use it without libc-dev - it's not a dependency. If you
want to do app cross-building you need a whole load of machinery, not
just libc-dev (cross-pkg-config, dpkg-cross (for autoconf caching),
etc), hence cross-build-essential packages to bring that in nicely for
people.
> > Is it just 'doko likes it like this'
>
> No, it was not his decision but mine. And it got merged after Emdebian
> developers agreed during sprint in ARM office.
I dunno. I just don't like the way that installing
arm-linux-gnueabi-4.7-gcc doesn't get me a working cross-gcc any more,
and nothing stops me making that mistake. It did when we used
/etc/alternatives. And the tradeoffs don't seem compelling. If we
could fix that I'd be happy.
Does the same problem exist in native-compiler land - I clearly never
notice there, presumably because one normally installs build-essential
or just 'gcc' not 'gcc-4.7'? I suppose we just have to get people used
to installing arm-linux-gnueabi-gcc or crossbuild-essential-armel then
things will 'just work'. Only people used to the old way will get
annoyed :-)
> > If I understand correctly the advantage of /etc/alternatives is that
> > you always get a symlink, whichever cross-gcc package you install.
> > The advantage of the generic cross-gcc package is that you can
> > install it without know anything about preffered versions (but if you
> > do install a specific version then you don't get a symlink at all).
> > But perhaps it is cleverer than that?
>
> Advantage is that we treat cross compiler in same way as native one.
> Nevermind how many gcc versions are available in archive the default one
> is default (even if not latest). U-A way does not warrant that.
This does have some value, especially for cross-building the archive
itself. It doesn't help much if you wanted to build other random
stuff, and need a specific compiler version for some reason. And I
agree our focus is on making it easy to cross-build packages rather
than 'other stuff' (although we want that to work too, preferably
without too much aggro).
U-A could update to poiunt at the default compiler when you install a new
cross-buid-essential if we wanted it to - couldn't it?
> > BTW: Why are we treating gcc/cpp/g++ differently from binutils and
> > pkg-config and anything else that needs a <triplet>-tool link? I
> > guess gcc packaging allows for installing multiple versions whilst
> > the other don't.
>
> There is one version of binutils in archive and there is no support for
> more than one installed. Same with pkg-config (but here you can just
> change location of *.pc files by environment variable).
Agreed. I just wanted to check that there was no call for a more
generic mechanism.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: