Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 500090 - waf-utils.eclass - Add cross-compile support
Summary: waf-utils.eclass - Add cross-compile support
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2014-02-02 13:41 UTC by James Le Cuirot
Modified: 2020-12-20 23:12 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
waf-utils.eclass.patch (waf-utils.eclass.patch,2.32 KB, patch)
2014-02-02 13:41 UTC, James Le Cuirot
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description James Le Cuirot gentoo-dev 2014-02-02 13:41:59 UTC
Created attachment 369344 [details, diff]
waf-utils.eclass.patch

I was putting my cross-compile scripts to the test so I thought I'd give Samba 3 and 4 a shot. Having only seen Waf used for XMMS2 before, I didn't expect it to have any concept of cross-compiling. Actually it's not half bad, possibly even better than autotools.

One option is to give --cross-answers and fill in the bunch of missing answers after the build fails, similar to how we provide answers to autotools with files from /usr/share/crossdev/include/site. Unfortunately these crossdev files can't be reused or remapped for use with Waf so it'll be down to the user to provide these. This is better than nothing so I have exposed this feature through the WAF_CROSS_ANSWERS variable.

The nicer alternative is --cross-execute, which runs the various tests through a userspace emulator such as QEMU. This works really well. I have exposed this through a variable called PORTAGE_EMULATOR that I think should feature in make.conf as it could potentially be used in other ways. Unfortunately variables like ${ROOT} are not usable in make.conf so I had to escape it and use eval in the eclass. I'm willing to discuss whether that is the best approach. Here's what them make.conf entry could look like.

# PORTAGE_EMULATOR is used by some ebuilds while cross-compiling when
#     it is necessary to execute a target binary on the build
#     host. This will typically point to a userspace emulator such as
#     qemu. Please escape variables such as ${ROOT} and watch out for
#     the sandbox as it usually breaks emulators.
#PORTAGE_EMULATOR="qemu-arm -L \${ROOT} -U LD_PRELOAD"

While I was at it, I found a much nicer workaround for the problem you were having with Waf's option parsing. Using set and "${@}" makes it much easier.

So I was able to successfully build Samba 3. Heimdal is currently blocking my path to Samba 4 but I am addressing that issue upstream.
Comment 1 James Le Cuirot gentoo-dev 2014-02-08 23:09:28 UTC
I have just realised why the sandbox wasn't working. It wasn't anything to do with running in an emulated environment. It was simply that I hadn't run ldconfig for the ROOT yet. Portage used to always run it but I had this changed way back in 2007 due to bug #152828. Requiring ldconfig would be complicated and sandbox may not be present in the ROOT anyway so I think -U LD_PRELOAD should stay but I've adjusted the wording slightly.

# PORTAGE_EMULATOR is used by some ebuilds while cross-compiling when
#     it is necessary to execute a target binary on the build
#     host. This will typically point to a userspace emulator such as
#     qemu. Please escape variables such as ${ROOT} and watch out for
#     the sandbox as it may not work inside the ROOT.
#PORTAGE_EMULATOR="qemu-arm -L \${ROOT} -U LD_PRELOAD"
Comment 2 Coacher 2017-01-26 20:09:14 UTC
I think this patch needs few additional bits for a proper pkg-config support.
Define PKGCONFIG environment variable pointing to /usr/bin/${CHOST}-pkg-config aka $(tc-getPKG_CONFIG).

Rationale: During configure phase waf figures out the path to pkg-config program by basically doing $(which pkg-config) and using the result. However, if 'PKGCONFIG' environment variable is defined, waf doesn't do detection and uses its value.

Of course, using '/usr/bin/pkg-config' in cross builds will pollute compiler's command line with flags like '-L/usr/lib', which inevitably leads to breakage.
Thus, defining 'PKGCONFIG' variable is a must for cross builds using waf.

[1]: https://github.com/waf-project/waf/blob/waf-1.9.7/waflib/Tools/c_config.py#L236
Comment 3 James Le Cuirot gentoo-dev 2017-01-26 20:21:36 UTC
Thanks for catching that. I'm still interested in this. I wondered whether the PORTAGE_EMULATOR bit would need to go into PMS (under a different name) but I suppose there's no harm in an eclass optionally supporting it.