Re: [RFC] [PATCH 0/9] Initial cross-compilation support

[Claudius Heine <ch@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 6158 bytes --]

Hi Henning,

On Thu, 2018-06-14 at 14:24 +0200, Henning Schild wrote:
> Am Thu, 14 Jun 2018 14:04:47 +0200
> schrieb Claudius Heine <ch@denx.de>:
> 
> > Hi,
> > 
> > On Wed, 2018-06-13 at 15:07 +0200, Alexander Smirnov wrote:
> > > Hi all,
> > > 
> > > this series introduces basic cross-compilation support for Isar.
> > > The
> > > implementation
> > > is based around new entity - buildchroot-cross, which is quite
> > > similar to original
> > > buildchroot, but has host architecture.  
> > 
> > Here is a crazy idea from me and Henning:
> > Have you tried just installing an amd64-arm cross toolchain into
> > the
> > existing arm buildchroot, then switch to it from the 'native'
> > toolchain using a combination of PATH variable entries, symlinks
> > and/or wrapper scripts and let binfmt deal with calling the amd64
> > binaries of the toolchain in the arm chroot environment?
> 
> Another idea that comes very close to the SDK series. How about the
> cross_build_chroot contains just the compiler and whatever the
> compiler
> needs. Then we mount buildchroot/rootfs into
> cross_build_chroot/sysroot
> and smuggle in the "--sysroot /sysroot/" i.e. by putting wrapper
> scripts for gcc and friends into /usr/local/bin/.
> 
> Similar approach, but we do not risk breaking the buildchroot by
> forcing an alien compiler into it.

Ok, maybe that was a misunderstanding. I meant installing the cross
compiler to a seperate directory inside the buildchroot and only
switching to it if needed by changing the PATH variable.

I currently don't understand how you solve the installation of the
dpkg-build-dependencies that way.

If you put the cross-compiler inside the buildchroot then you can just
chroot into it to build and install dependencies. The other way around
is not so obvious to me.

>  And we use less binfmt magic ...
> Both the cross-compile and the SDK are very similar and if cross
> builds
> on top of SDK we should be on the right track.

I do like the idea to merge the SDK and cross-build patchset somewhat,
since they do have a similar goal.

Cheers,
Claudius

> 
> Henning
> 
> > This way the arm system would think that you are compiling nativly
> > while in fact you are using a cross compiler that is not emulated.
> > 
> > Would that work?
> > 
> > Cheers,
> > Claudius
> > 
> > > 
> > > This series tested for the following configuration only:
> > > 
> > >  $ bitbake multiconfig:qemui386
> > > 
> > > In this build:
> > >  - libhello is cross-compiled
> > >  - example-hello is compiled traditionally (but it's successfully
> > > linked with libhello)
> > > 
> > > TODO list:
> > >  - Depending on the target architecture, various host tools
> > > should
> > > be installed. For example
> > >    binutils package has the following names:
> > >    * binutils
> > >    * binutils-x86-64-linux-gnu
> > >    * binutils-arm-linux-gnueabihf
> > >  - Cross-dependency installation. This topic is still open for me
> > > because 'mk-build-deps' tool
> > >    doesn't work here correctly. For example package depends on
> > > binutils, but instead of
> > >    installation of 'binutils-arm-linux-gnueabihf' it tries to
> > > install 'binutils:armhf' and ruins
> > >    the rootfs.
> > > 
> > > So, as usually, comments and suggestions are welcome :-)
> > > 
> > > With best redgards,
> > > Alex
> > > 
> > > Alexander Smirnov (9):
> > >   isar-bootstrap: Add routin to determine host arch
> > >   isar-bootstrap: Move common part to include
> > >   isar-bootstrap: Add host architecture support
> > >   isar-bootstrap-helper: Add parameter to set arch
> > >   buildchroot-cross: Initial implementation
> > >   classes/dpkg*: Relocate dependency from buildchroot
> > >   classes/dpkg*: Drop hardcoded buildchroot blobs
> > >   classes/dpkg-cross: Initial implementation
> > >   [FOR TESTING] libhello: Switch to cross compilation
> > > 
> > >  meta-isar/recipes-app/libhello/libhello.bb         |   2 +-
> > >  meta/classes/dpkg-base.bbclass                     |  17 +-
> > >  meta/classes/dpkg-cross.bbclass                    |  15 ++
> > >  meta/classes/dpkg-raw.bbclass                      |   7 +-
> > >  meta/classes/dpkg.bbclass                          |   7 +-
> > >  meta/classes/image.bbclass                         |   2 +-
> > >  meta/classes/isar-bootstrap-helper.bbclass         |  13 +-
> > >  meta/conf/isar-bitbake.conf                        |   1 +
> > >  .../isar-bootstrap/isar-bootstrap-host.bb          |  44 ++++
> > >  .../isar-bootstrap/isar-bootstrap-target.bb        |  44 ++++
> > >  meta/recipes-core/isar-bootstrap/isar-bootstrap.bb | 259 -----
> > > ----
> > > ------------
> > >  .../recipes-core/isar-bootstrap/isar-bootstrap.inc | 223
> > > ++++++++++++++++++
> > >  .../buildchroot/buildchroot-cross.bb               |  53 +++++
> > >  meta/recipes-devtools/buildchroot/buildchroot.bb   |   2 +-
> > >  .../buildchroot/files/build-cross.sh               |  29 +++
> > >  15 files changed, 443 insertions(+), 275 deletions(-)
> > >  create mode 100644 meta/classes/dpkg-cross.bbclass
> > >  create mode 100644 meta/recipes-core/isar-bootstrap/isar-
> > > bootstrap-
> > > host.bb
> > >  create mode 100644 meta/recipes-core/isar-bootstrap/isar-
> > > bootstrap-
> > > target.bb
> > >  delete mode 100644 meta/recipes-core/isar-bootstrap/isar-
> > > bootstrap.bb
> > >  create mode 100644 meta/recipes-core/isar-bootstrap/isar-
> > > bootstrap.inc
> > >  create mode 100644 meta/recipes-
> > > devtools/buildchroot/buildchroot-
> > > cross.bb
> > >  create mode 100644 meta/recipes-
> > > devtools/buildchroot/files/build-
> > > cross.sh
> > > 
> > > -- 
> > > 2.1.4
> > >   
> 
> 
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

            PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
                              Keyserver: hkp://pool.sks-keyservers.net

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]