FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 01-25-2012, 12:58 PM
DrEagle
 
Default cross-build-essential

Hi all,

I have not so time available too, but :
- I need a good cross toolchain solution for armel/armhf.
- I use debian on my sheevas and desktops
- I have allready made a port of DoudouLinux Debian based system on
Genesi SmartBook
- I have a lot of others projects still in progress or in standby...

Le 23/01/2012 16:28, Wookey a écrit :
> However right now no-one is really working on this much. Hector is
> busy with armhf stuff (and a new job). I'm working on sbuild/buildd
> multiarch cross-building.
>
> If anyone wants to take the glory by actually making this work (it
> probably isn't very hard at this stage) you are very welcome. The
> debian-embedded list is the place where this stuff gets discussed.

I can be interested by taking the glory by making things works.
- What are the needed stuff ?
- How can I start study what had been already done ?
- What's next to be acomplish ?
- Who can help in taking needed informations, best practice, and stuff
that I may forget ?

SeeYouSoon...
---
DrEagle
 
Old 06-27-2012, 07:04 PM
Wookey
 
Default cross-build-essential

+++ Wookey [2012-01-19 14:32 +0000]:
> +++ Neil Williams [2012-01-19 13:02 +0000]:
> > On Thu, 19 Jan 2012 12:10:28 +0000
> > Wookey <wookey@wookware.org> wrote:
> >
> > > I've thought for a long time that a package like build-essential for
> > > cross-building would be a really good idea.
> >
> > +1
> >
> > It should probably depend on build-essential itself as a starting point.
>
> I suppose so. You won't get far without that.

OK, there has been progress in this area. Thanks to Patrick McDermmot
(GSOC student) we have a patch to add support to build-essential for a
crossbuild-essential-<arch> packages.

http://odin1.pehjota.net/~pj/debian-bootstrap/build-essential/

The initial patches there add crossbuild-essential packages to the
build-essential source, which is easy to do but leads to some questions.

1) Some of the packages that cross-build-essential depends on (cross-compiler
packages) are not yet in the archive, and won't be in wheezy. That
means that these packages will not be installable and thus will not
migrate from unstable until the cross-compiler packages do arrive.

That seems like a very good reason to keep cross-build-essential as a
separate source package for now, available from emdebian.org, along
with the toolchains. Anyone disagree?

2) Is the build-essential maintainer happy to include this code once
the resulting packages _are_ installable? Or in the same way that he
(doko) likes to keep the cross-toolchains separate should we keep them
separate for the forseeable future?

Does that change once everything is built in the archive?

Is the maintainer happy with the implementation above? It uses the
existing machinery of build-essential to be compatible but is still
somewhat intrusive.


A bit of background here for those who aren't following all the details:

We are working towards having cross-compilers in the archive. The plan
is for those toolchains to use multiarch so that the existing
libc:<arch> linux-libc-dev:<arch> libgcc1:<arch> etc packages in the
archive are used by the cross-toolchains, rather than being rebuilt
and renamed as foo-cross packages (where practical).

Prototypes of those packages for i386 and amd64 are now available at:
http://emdebian.org/~thibg/repo/

You can't install them without having the modified dpkg (also in that
repo) which allows depends:<arch> (i.e a specific arch) syntax.

We are hopeful that that dpkg change will just scrape into wheezy so
that these toolchains will be easily usable without having to have a
nobbled dpkg to hand.

This work, combined with sbuild's already-in-wheezy config to set up
multiarch and install crossbuild-essential-<arch>, and the forthcoming
<triplet>-pkg-config packages, should make for painless cross-building
(modulo suitable multiarch metadata in packages and packages that are
actually capble of being cross-built).

I'll give a more complete summary of current state at debconf.

Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120627190426.GG26362@dream.aleph1.co.uk">http://lists.debian.org/20120627190426.GG26362@dream.aleph1.co.uk
 
Old 06-27-2012, 08:03 PM
Neil Williams
 
Default cross-build-essential

On Wed, 27 Jun 2012 20:04:26 +0100
Wookey <wookey@wookware.org> wrote:

> A bit of background here for those who aren't following all the details:
>
> We are working towards having cross-compilers in the archive. The plan
> is for those toolchains to use multiarch so that the existing
> libc:<arch> linux-libc-dev:<arch> libgcc1:<arch> etc packages in the
> archive are used by the cross-toolchains, rather than being rebuilt
> and renamed as foo-cross packages (where practical).

... this is a pre-requisite for restarting work on Emdebian Crush
after Wheezy which will extend Embedded Debian to offer a Debian system
without coreutils, with a rebuilt busybox and likely without perl. The
premise will be to only cross-build the packages which need functional
changes and pull the rest from Emdebian Grip. (As a special-case,
partial archive, packages for Emdebian Crush will stay on emdebian.org
servers/mirrors.)

So this is a very welcome development. Unlike the one-off release of
Crush for the old ARM port based on Lenny, Multiarch should be capable
of delivering support for multiple architectures - probably 4.

Where packages are changed for Crush, we'll start using -crush suffixes
to source package names. (e.g. busybox-crush, cairo-crush).

http://www.emdebian.org/trac/browser/current/target

(Those versions are old but the idea is the same.)

I'm also hoping that the existing QtEmbedded build can be provided,
somehow.

http://lists.debian.org/debian-embedded/2011/10/msg00023.html

Integrating these changes into the relevant Debian packages via
build-options is a different question which can also be broached
@DebConf.

> This work, combined with sbuild's already-in-wheezy config to set up
> multiarch and install crossbuild-essential-<arch>, and the forthcoming
> <triplet>-pkg-config packages, should make for painless cross-building
> (modulo suitable multiarch metadata in packages and packages that are
> actually capble of being cross-built).

(Just one of the reasons to only cross-build for Crush what we actually
need to modify - bootstrapping will need wider coverage.)

> I'll give a more complete summary of current state at debconf.

Anyone wanting to talk about the details of creating a very small
Debian distribution for specific targets can also talk to myself or
Wookey at DebConf. This can be part of the proposed Emdebian BoF.

A new version of Crush using Multiarch cross-compilers should get us
back to a sub 32Mb install of a Debian system, maybe sub 20Mb. (Sub
16Mb means using uClibc which is a harder problem.)

Anyone with ideas on how to prune the iconv files normally provided
with eglibc:libc6? Find me/Wookey @/during DebConf.

http://www.emdebian.org/emdebian/flavours.html

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 06-28-2012, 09:17 AM
Goswin von Brederlow
 
Default cross-build-essential

Wookey <wookey@wookware.org> writes:

> +++ Wookey [2012-01-19 14:32 +0000]:
>> +++ Neil Williams [2012-01-19 13:02 +0000]:
>> > On Thu, 19 Jan 2012 12:10:28 +0000
>> > Wookey <wookey@wookware.org> wrote:
>> >
>> > > I've thought for a long time that a package like build-essential for
>> > > cross-building would be a really good idea.
>> >
>> > +1
>> >
>> > It should probably depend on build-essential itself as a starting point.
>>
>> I suppose so. You won't get far without that.
>
> OK, there has been progress in this area. Thanks to Patrick McDermmot
> (GSOC student) we have a patch to add support to build-essential for a
> crossbuild-essential-<arch> packages.
>
> http://odin1.pehjota.net/~pj/debian-bootstrap/build-essential/
>
> The initial patches there add crossbuild-essential packages to the
> build-essential source, which is easy to do but leads to some questions.
>
> 1) Some of the packages that cross-build-essential depends on (cross-compiler
> packages) are not yet in the archive, and won't be in wheezy. That
> means that these packages will not be installable and thus will not
> migrate from unstable until the cross-compiler packages do arrive.
>
> That seems like a very good reason to keep cross-build-essential as a
> separate source package for now, available from emdebian.org, along
> with the toolchains. Anyone disagree?

I wonder what the difference is between cross-build-essential and
build-essential in terms of packages and wether we need a seperate
package at all.

Say I want to have the build-essential for i386 installed on amd64.
I could install build-essential:i386, replacing gcc/g++:amd64 with
gcc/g++:i386. Wouldn't that give me everything needed to cross-compile
for i386?

That said wouldn't it make sense to have build-essential use

Depends: g++:<arch> (>= <ver>) | g++-cross-<arch> (>= <ver>)

Since build-essential is architecture any it already pulls in the
foreign libraries needed for that arch. Only difference would be that
since g++:<foreign> conflicts with the g++:<native> frontends would
choose g++-cross-<arch> instead.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/87wr2rlrs2.fsf@frosties.localnet
 
Old 06-28-2012, 09:29 AM
Simon McVittie
 
Default cross-build-essential

On 28/06/12 10:17, Goswin von Brederlow wrote:
> Say I want to have the build-essential for i386 installed on amd64.
> I could install build-essential:i386, replacing gcc/g++:amd64 with
> gcc/g++:i386. Wouldn't that give me everything needed to cross-compile
> for i386?

For evolutions of the same CPU family (i386 vs amd64, powerpc vs
powerpc64) this sort of works, but after you've installed gcc:i386, you
can't compile 64-bit code any more (until you reinstall gcc:amd64). That
means that in practice you use a chroot for 32-bit compilation, and if
you're doing that, it might as well be a purely i386 chroot that doesn't
use multiarch.

For "real" cross-compiling - amd64 vs armel, say - you don't really want
to be running an armel gcc binary that emits armel machine code (which
is what gcc:armel is) under qemu emulation: it's technically possible,
but your build will be rather slow. What you want is an amd64 gcc binary
that emits armel machine code, which is what gcc-cross-armel:amd64 contains.

S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FEC23F0.10806@debian.org">http://lists.debian.org/4FEC23F0.10806@debian.org
 
Old 06-28-2012, 09:43 AM
Svante Signell
 
Default cross-build-essential

On Thu, 2012-06-28 at 10:29 +0100, Simon McVittie wrote:
> On 28/06/12 10:17, Goswin von Brederlow wrote:
> > Say I want to have the build-essential for i386 installed on amd64.
> > I could install build-essential:i386, replacing gcc/g++:amd64 with
> > gcc/g++:i386. Wouldn't that give me everything needed to cross-compile
> > for i386?
>
> For evolutions of the same CPU family (i386 vs amd64, powerpc vs
> powerpc64) this sort of works, but after you've installed gcc:i386, you
> can't compile 64-bit code any more (until you reinstall gcc:amd64). That
> means that in practice you use a chroot for 32-bit compilation, and if
> you're doing that, it might as well be a purely i386 chroot that doesn't
> use multiarch.
>
> For "real" cross-compiling - amd64 vs armel, say - you don't really want
> to be running an armel gcc binary that emits armel machine code (which
> is what gcc:armel is) under qemu emulation: it's technically possible,
> but your build will be rather slow. What you want is an amd64 gcc binary
> that emits armel machine code, which is what gcc-cross-armel:amd64 contains.

The situation is even more complicated if compiling for different OSes:
Like as host (build) Linux:i386 and guest (target) kFreeBSD:amd64 or
Hurd:i386. Any plans to support such combinations with
cross-build-essential?



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/1340876597.32095.129.camel@hp.my.own.domain
 
Old 06-28-2012, 11:29 AM
Simon McVittie
 
Default cross-build-essential

On 28/06/12 10:43, Svante Signell wrote:
> The situation is even more complicated if compiling for different OSes:
> Like as host (build) Linux:i386 and guest (target) kFreeBSD:amd64 or
> Hurd:i386. Any plans to support such combinations with
> cross-build-essential?

It shouldn't differ from compiling for different CPUs: the key problem
in cross-compilation is "your build system can't run your host system's
binaries", which you can arrive at either via differing OSs or differing
CPUs. (Or both, of course.)

Either way, you need to have development libraries for the host system
installed on the build system, and a compiler that can be executed on
the build system, but links against those host system development
libraries and produces machine code for the host system. So, if
cross-build-essential works for x86-64/Linux to armel/Linux
cross-compilation, I don't see any reason why the same techniques
wouldn't work equally well for x86-64/Linux to i386/Hurd.

A note on terminology: in cross-compiling, the standard meaning of
"host" doesn't match how you used it. If I cross-compile a package for
armel on an i386 machine, armel is the "host architecture" and i386 is
the "build architecture".

There is a third variable, "target", which is only used for compilers,
linkers and similar tools: to compile that package, I would have needed
a compiler built for an i386 "host architecture" with an armel "target
architecture".

S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FEC4015.7070701@debian.org">http://lists.debian.org/4FEC4015.7070701@debian.org
 
Old 06-28-2012, 11:47 AM
Wookey
 
Default cross-build-essential

+++ Svante Signell [2012-06-28 11:43 +0200]:
>
> The situation is even more complicated if compiling for different OSes:
> Like as host (build) Linux:i386 and guest (target) kFreeBSD:amd64 or
> Hurd:i386. Any plans to support such combinations with
> cross-build-essential?

Multiarch should support this and dpkg-architecture already does. So
if someone wants to maintain toolchains to do this then adding an
entry to cross-build-essential is easy. (We didn't put everything
possible supported by dpkg in, because that would be 271 packages :-)
Does it actually need a conventional cross-toolchain or is it like the
amd64/i386 case where a chroot and a personality is all that is needed?

I admit that I haven't thought about the issues for this particular
case in any detail. Is there actually a demand for being able to do
this?

Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120628114748.GW13768@stoneboat.aleph1.co.uk">htt p://lists.debian.org/20120628114748.GW13768@stoneboat.aleph1.co.uk
 
Old 06-28-2012, 06:22 PM
Ben Hutchings
 
Default cross-build-essential

On Thu, Jun 28, 2012 at 10:29:20AM +0100, Simon McVittie wrote:
> On 28/06/12 10:17, Goswin von Brederlow wrote:
> > Say I want to have the build-essential for i386 installed on amd64.
> > I could install build-essential:i386, replacing gcc/g++:amd64 with
> > gcc/g++:i386. Wouldn't that give me everything needed to cross-compile
> > for i386?
>
> For evolutions of the same CPU family (i386 vs amd64, powerpc vs
> powerpc64) this sort of works, but after you've installed gcc:i386, you
> can't compile 64-bit code any more (until you reinstall gcc:amd64).
[...]

Sure you can (-m64). (But you'll need to have the proper headers
installed.)

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120628182159.GY2753@decadent.org.uk">http://lists.debian.org/20120628182159.GY2753@decadent.org.uk
 
Old 06-29-2012, 12:39 AM
Adam Borowski
 
Default cross-build-essential

On Thu, Jun 28, 2012 at 12:29:25PM +0100, Simon McVittie wrote:
> On 28/06/12 10:43, Svante Signell wrote:
> > The situation is even more complicated if compiling for different OSes:
> > Like as host (build) Linux:i386 and guest (target) kFreeBSD:amd64 or
> > Hurd:i386. Any plans to support such combinations with
> > cross-build-essential?
>
> It shouldn't differ from compiling for different CPUs: the key problem
> in cross-compilation is "your build system can't run your host system's
> binaries", which you can arrive at either via differing OSs or differing
> CPUs. (Or both, of course.)

It's not just that: if qemu-user is enabled, you will be able to run target
system's binaries, although at a prohibitively slow speed. The last time I
tried, it was a matter of 8 hours vs 44 seconds[1].

So we have the following cases:

0. primary arch
1. secondary arch that can run on native speeds
2. secondary arch that goes through qemu
3. secondary arch with no qemu enabled
4. non-multiarch cross compiler[2]

You are talking about the distinction between 0-2 vs 3-4, while there's a
reason to avoid 2 if possible (yet it's more likely to succeed than 3).

It'd be nice to specify the dependency in a way that doesn't make
build-essential:armel prefer gcc:armel over gcc-armel-cross:amd64.

Otherwise, I agree with you that multi-arch build-essential are so much
better than cross-build-essential.

> A note on terminology: in cross-compiling, the standard meaning of
> "host" doesn't match how you used it. If I cross-compile a package for
> armel on an i386 machine, armel is the "host architecture" and i386 is
> the "build architecture".

It's a terrible choice of names: outside of autotools world, everyone
assumes that "host" is the architecture you're running the cross build on,
hosting qemu on, etc. Kernel-like build systems for example print:
HOSTCC something
CC something
This is the intuitive naming.

> There is a third variable, "target", which is only used for compilers,
> linkers and similar tools: to compile that package, I would have needed
> a compiler built for an i386 "host architecture" with an armel "target
> architecture".

And outside of autotools, "target" is the target of your compilation.
Confusion ensues.

Too bad, I have no idea how to make it unambiguous. None of the three words
is safe; even "build" would cause gems like BUILDCC which is unobvious at
the very least.


[1]. That was qemu-system, I guess qemu-user would at least be able to use
more than one core, and avoid a crippling memory limit.

[2]. And that's not even exhaustive. Just today, running "make clean" on
something spawned a wine popup about updating some config, and the build log
included:
checking for suffix of executables... .exe
checking whether we are cross-compiling... no

--
Sanity is overrated anyway.
 

Thread Tools




All times are GMT. The time now is 02:55 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org