Bug 10128 - Cross compilation is broken since version 4.1
Cross compilation is broken since version 4.1
Status: RESOLVED FIXED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Build
unspecified
All All
: P1 regression
: ---
Assigned To: Björn Jacke
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-06 11:21 UTC by Christophe Vu-Brugier
Modified: 2016-11-21 01:16 UTC (History)
8 users (show)

See Also:


Attachments
gzip compressed config.log (47.79 KB, application/gzip)
2013-09-06 11:23 UTC, Christophe Vu-Brugier
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christophe Vu-Brugier 2013-09-06 11:21:59 UTC
Since commit "cd4b413 build: Remove autoconf build system", there is
only one build system for Samba: waf. Unfortunately, cross compilation
is broken with waf.

I use the following shell script to cross compile Samba:

#!/bin/sh

PATH="$PATH:/opt/gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux/bin/"
CC=arm-linux-gnueabihf-gcc

CONFIGURE_OPTIONS=''

CROSS_COMPILE_OPTIONS='\
    --cross-compile \
    --cross-execute=/usr/bin/qemu-arm \
'

CC=$CC buildtools/bin/waf configure $CONFIGURE_OPTIONS $CROSS_COMPILE_OPTIONS build
 
Please see the attached config.log file for more details.
Comment 1 Christophe Vu-Brugier 2013-09-06 11:23:10 UTC
Created attachment 9193 [details]
gzip compressed config.log
Comment 2 Andrew Bartlett 2013-10-15 20:37:21 UTC
Jermey,

You raised this on samba-technical.  Do you have such an environment already, that you have reproduced this on?

Otherwise, can someone provide instructions for setting up a cross-compilation environment on either Debian Wheezy or Fedora 19 to reproduce this, or can someone provide such a VM?

The only way we will be able to maintain this long-term is if such support is added to autobuild.

Thanks,
Comment 3 Jeremy Allison 2013-10-15 20:44:21 UTC
I don't yet unfortunately, but I have 4 OEMs who have flagged this as a severe problem for them.

I'll get them to give us a cross-compiling environment so we can ensure we've got this right.

Jeremy.
Comment 4 Christophe Vu-Brugier 2013-10-16 07:28:32 UTC
Dear Andrew Bartlett,

Here are the instructions to try to build Samba 4.1 for ARM with WAF.

1/ You need a cross-compiler for ARM. You can download such a compiler
   from Linaro:

   https://launchpad.net/linaro-toolchain-binaries/trunk/2013.08/+download/gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux.tar.xz

2/ The cross-compiler is an i386 binary, so if you are running an
   x86_64 distribution, then you need to install the i386 versions of
   libc6 and libstdc++. On Debian, you can add the "i386" foreign
   architecture and install libc6:i386 and libstdc++6:i386.

3/ You also need the Qemu emulator for ARM (package qemu-user on
   Debian)

4/ Try to compile a simple "hello world" program to ensure that your
   cross-compiler runs fine. Also try to run the program with
   qemu-arm:

   $ arm-linux-gnueabihf-readelf -h hello | grep Machine
     Machine:                           ARM
   $ qemu-arm hello
   Hello, World!

Then, you can try to compile Samba with WAF:

   $ CC=arm-linux-gnueabihf-gcc buildtools/bin/waf configure \
     --cross-compile --cross-execute=/usr/bin/qemu-arm

The configure step will fail because you need a version of Python
built for the target. You can build one with Buildroot or you can use
this one that I built:

  http://www.enodev.fr/for-abartlett/rootfs.tar

I will attach the ugly patches I am using to pass the configure
step. I don't have access to them right now.
Comment 5 David Hauck 2015-03-10 17:36:55 UTC
Doesn't seem to be much activity on this P1 regression bug. I also don't see any other dependencies that might have superseded the tracking of this issue. Is this issue still a high priority for fixing? 

I'm currently trying to cross-build (host: x86_64; target: i686) and this is also failing for me due to the Python complication. From what I can tell out of the box cross-compilation support of Samba v4.1+ is broken.

Thanks,
-David
Comment 6 Andrew Bartlett 2015-03-11 03:03:29 UTC
Have you tried Samba 4.2?

Check out in particular the magic python_LIBS and python_CFLAGS env variables.
Comment 7 Christophe Vu-Brugier 2015-03-11 08:11:54 UTC
(In reply to David Hauck from comment #5)

As stated by Andrew Bartlett, Samba 4.2 contains everything you need to cross-compile Samba 4. For instance, Buildroot (an embedded build system) contains a recipe to cross-compile Samba 4:

  http://git.buildroot.net/buildroot/tree/package/samba4/samba4.mk
Comment 8 David Hauck 2015-03-11 13:55:24 UTC
(In reply to Christophe Vu-Brugier from comment #7)
Thanks for these tips (both the python_* and buildroot pointers) - I'll give these a try and report back. At which point (assuming success - already supposedly proven by buildroot) it seems this issue should be closed.
Comment 9 Andrew Bartlett 2015-03-12 01:08:49 UTC
Marking as fixed in 4.2.0.
Comment 10 Andrew Bartlett 2015-03-12 01:09:47 UTC
(In reply to Christophe Vu-Brugier from comment #7)

Any chance you can create a page on our wiki describing this?

Thanks!
Comment 11 David Hauck 2015-03-12 01:16:11 UTC
(In reply to Andrew Bartlett from comment #9)

Hi Andrew, I was just in the middle of putting together some text regarding my (sporadic) work on this today ;). I'm making progress, but still not completely there. I'd like to report these findings tomorrow if possible - maybe they'll be helpful and/or might solicit further feedback.
Thanks,
-David
Comment 12 Jeremy Allison 2015-03-31 20:22:44 UTC
I have finally had some success with:

http://buildroot.uclibc.org/

in generatin 4.1.x and 4.2.x ARM binaries without using the QEMU method !
Comment 13 Uri Simchoni 2015-04-13 18:34:50 UTC
xxx
Comment 14 David Hauck 2015-04-13 18:42:11 UTC
OK, finally getting back to this (recovering from a sport's related concussion is a slow process ;)). I'd like to look at the new wiki reference (which I haven't see a pointer to yet) to see how closely it matches my findings; I definitely struggled with the proper Python configuration/references during the cross-build and ended up settling on using PYTHON, python_LDFLAGS, python_LIBDIR, and INCLUDEPY during the configure stage and PYTHON_INCLUDES during the build stage.
Comment 15 Uri Simchoni 2015-04-13 19:18:39 UTC
(Sorry about last xxxcomment)
I built samba 4.2.0 on a custom embedded system now, and the major hurdles to overcome were as follows:
1. libldap.so depends on other shared libraries (openssl). With a native linker, the linker would typically find those, but with a cross linker, the -L parameter is not enough (it is being used for finding -l<lib> but not for dependencies of those libs). On samba3 there was the LDAP_LIBS configuration variable to handle this. Here came -rpath-link switch to the rescue - for each -L switch in LDFLAGS I also added a corresponding -rpath-link switch, telling the linker where to look for those dependent libs (e.g. if LDFLAGS was "-L /foo" now it's "-L /foo -Xlinker -rpath-link=/foo)

2. Python (sigh). You really need a functioning python-config for the target, that can run on the host. So that when you run "python-config --includes" it will print out the include directories for the target's python, on the build machine. Python 2.7 doesn't have that out-of-the box. You can backport the fix from Python 3, as buildroot are doing, but I had to tweak that too. Bottom line is that python-config --includes must be correct. Then you put it in configure's environment (PYTHON_CONFIG=/path/to/target/python-config ./configure)

3. Strangely, for Python libraries and link flags, python-config is not consulted. I wish it were because if you get it right, that solves everything. There's a partial solution in the form of python_LIBDIR (which allows you ONLY to add to linker search path) and python_LDFLAGS (which allows you ONLY to set more link flags). Best thing is to set them to empty string, relying on existing LDFLAGS that already points to python libs. However, the additional libraries to link against (additional -l flags) are taken from the build machine python (distutils) and that's a bug. Luckily for me they were the same, but even if my target python was statically-linked, I would run into a problem b/c the order of libraries included is dependencies first, python second. 

Another issue I encountered was that my embedded kernel didn't support IPv6 and I couldn't find a way in the build system to disable IPv6 - IPv6 was enabled based on it being supported by libc. That means smbd cannot listen to connections. My fix for that was simply to add IPv6 support.

So to summarize:
PYTHON_CONFIG=/path/to/my/target python-config \
python_LDFLAGS="" \
python_LIBDIR="" \
LDFLAGS="${LDFLAGS} -Xlinker -rpath-link=/path/to/openssl/libs \
./configure --cross-compile --cross-answeres=/my/answers/file ....