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.
Created attachment 9193 [details] gzip compressed config.log
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,
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.
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.
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
Have you tried Samba 4.2? Check out in particular the magic python_LIBS and python_CFLAGS env variables.
(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
(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.
Marking as fixed in 4.2.0.
(In reply to Christophe Vu-Brugier from comment #7) Any chance you can create a page on our wiki describing this? Thanks!
(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
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 !
xxx
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.
(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 ....