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

Re: multiarch compatible cross compilers for Jessie

On Monday 6. October 2014 01.30.16 Wookey wrote:
> +++ Paul Boddie [2014-10-05 20:01 +0200]:
> > 
> > https://bugs.launchpad.net/ubuntu/+source/gcc-defaults-armel-cross/+bug/6
> > 00930
> > 
> > I suppose that the "resolution" of this matter by providing the
> > gcc-defaults- armel-cross package isn't really a proper solution. Unless
> > one manually makes a symbolic link for gcc (in my case,
> > mipsel-linux-gnu-gcc, I guess), it appears necessary for me to edit
> > debian/rules files to set CC manually wherever configure is called,
> > although I could be missing some debhelper mechanism that would normally
> > be invoked to deal with this.
> I don't see why having some package provide an arm-linux-gnueabi-gcc
> link to the correct gcc version ( arm-linux-gnueabi-gcc-4.9) is 'a
> hack'. It's exactly what we do for the native compilers. I agree that
> the package that does that is currently missing. Our plan is for the
> gcc-defaults package to expand to provide these links for
> cross-toolchains too. Or it could be done by an <arch>-cross-support
> package

What I meant was that without being able to have a "default" cross-gcc be 
found by configure for the required architecture (not just for armel), and 
setting CC to gcc-4.9 wasn't enough in my experiments - it had to be mipsel-
linux-gnu-gcc-4.9, or $(DEB_HOST_GNU_TYPE)-gcc-4.9 to be slightly more general 
- it makes it hard to cross-build packages the multiarch way without having to 
go in and change debian/rules files specially for the task of cross-building, 
although I concede that I may have missed some debhelper magic to make this 
happen for me. That was the ugly hack, if anything.

The generic symbolic link for gcc is precisely what is required (subject to 
configure behaving itself, I guess) - they all exist for the binutils programs 
- and I noticed that this had been mentioned in the context of gcc-defaults, 
so I wondered what the status of something like that might be. I didn't really 
know where to start in trying to build gcc-defaults to produce packages 
providing those links.

> > Another thing is the matter of programs like pkg-config:
> > 
> > https://bugs.launchpad.net/ubuntu/+source/gcc-defaults-armel-cross/+bug/7
> > 71569
> > 
> > Again, the suggested solution of manually making a symbolic link for a
> > target platform seems like a bit of a hack, really, but it does seem to
> > make cross- builds work without any extra effort.
> Doing it by hand is tiresome (not really 'hacky' IMHO). Having a
> package that installs it for you is perfectly sensible. We propose
> that an <arch>-cross-support package will install this link.

Well, what concerns me here just as above is the special-casing required to 
have the right pkg-config be used. If debhelper can be taught about the 
special script then that would be a reasonable alternative to a package making 
the link, I imagine. Manually adding entries in /usr/bin isn't really the way 
to go in a system where the package manager looks after these directories, as 
I'm sure everyone agrees.

> There is a actually a much cooler way to do this - let multiarch bring
> in the correct pkg-config:arch package which will contain said
> symlink. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759556
> This stops pkg-config being special-cased. However the maintainer did
> not like our solution much so the simple ubuntu-style symlink is
> likely to be how it's done in jessie.
> > I suppose no further consensus was
> > reached about providing platform-specific pkg-config programs or links.
> It has been discussed, as above.

Again, the worry is that if a set of additional manual steps needs to be 
remembered and introduced to get things working, the effort (and frustration) 
involved in achieving successful cross-builds will remain relatively high. 
Having seen a wide selection of guides to cross-building, an additional 
concern is that the right way, having to be explicitly described and not 
completely automated, gets obscured by material covering the many wrong or old 
ways. (I understand that the situation remains fluid, though, so the potential 
for automation and the mechanisms involved are affected by limitations imposed 
by other things.)

> > Anyway, after a couple of successful cross-builds (involving the
> > libvorbisidec and sdl-mixer1.2 source packages), those are my
> > experiences so far. Thanks to everyone who has made this possible!
> No probs - no if we can just get some toolchains uploaded to Jessie,
> more people will be able to use this. Time is running out... (I'm
> working on it right now, in fact)

Once again, I appreciate your efforts and hope that the toolchains do indeed 
reach a wider audience. Thanks once again!


Reply to: