[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debian-bootstrap] An apparent need for gcc-<triplet>, cpp-<triplet>, g++-<triplet>, etc.

+++ Marcin Juszkiewicz [2012-07-02 12:56 +0200]:
> W dniu 02.07.2012 12:52, Wookey pisze:
> > +++ P. J. McDermott [2012-07-01 20:00 -0400]:
> >> Thibaut and Wookey,

[moving the discussion to debian-embedded - context starts at
if the below doesn't make sense. We are just talking about the fact
that cross-gcc packages need a symlink to the actual vX.X cross-gcc
(and cpp and g++) binaries in use. This used to be done with
alternatives and is now done with a generic gcc-<triplet> package to
match the native case. In Debian this latter part isn't being done at
all right now so you end up smylinkless]

> >> So we need symbolic links, e.g. /usr/bin/arm-linux-gnueabihf-gcc
> >> -> arm-linux-gnueabihf-gcc-4.7.  Working around this is of course 
> >> easy, and I've updated my sbuild setup notes [1] accordingly.
> > 
> > At some point Marcin changed things in the ubuntu packaging so now 
> > there is a package gcc-arm-linux-gnueabi (and cpp-arm-linux-gnueabi) 
> > which I guess is doing this the same way the gcc native does it. If 
> > you don't install this package then you don't get a symlink at all 
> > and the toolchain doesn't work.
> 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.

> >> Default Versions of Cross Compilers and Preprocessors 
> >> -----------------------------------------------------

> > My questions are: how does it work for native gcc? And reason not to
> >  do the same thing in cross-world?
> 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. 

How do you switch the symlink if you want to use a different version?

What is the advantage of this method over /etc/alternatives? Is it
just 'doko likes it like this' (which is a relevant argument, I agree)

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?

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. Is there a good reason for multiple cross-gcc version support
but not other tools? I guess it's just that the package supports this
and we have to deal with it.

> > Are 'alternatives' sufficient?
> Adding back support for update-alternatives may get blocked by gcc
> maintainer (Matthias Klose).

OK. That is clearly a consideration. I won't pester him until I
actually understand what's happening now and why (or that we don't
know why).

Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM

Reply to: