The Samba-Bugzilla – Bug 13846
cross-compile will not take cross-answers or cross-execute
Last modified: 2019-07-29 05:43:22 UTC
Created attachment 14955 [details]
workaround for the issue
There are 2 problems after 4.10 upgrading the waf:
1) run_prefork_process may not use cross_Popen (which is the wrapper of Utils.subprocess.Popen)
2) cross compile argument is not taken (Specific, exec_args which we get from conf.SAMBA_CROSS_ARGS)
Steps to Reproduce:
1) ./configure --cross-compile --cross-answers=XXX
2) the cross-answers will not apply.
after 4.10.0 rc
Created attachment 15040 [details]
fix rpath, related to the previous commit
A few of us (at OpenWrt) have been looking to upgrade the Samba package from 4.9.8 to 4.10.2 and we're seeing this same issue (https://github.com/openwrt/packages/pull/8944). I've tried 4.10.4 with the same results.
I've also tried the changes proposed in this report and they appear to work correctly.
Would be great if this can be addressed soon :-)
Comment on attachment 14955 [details]
workaround for the issue
>From a197e0cafb276a9b732f914b1f679ebb487b47f1 Mon Sep 17 00:00:00 2001
>From: pinglin <email@example.com>
>Date: Tue, 19 Mar 2019 20:46:27 +0800
>Subject: [PATCH] cross_compile argument doesn't apply
> ./configure --cross-compile --cross-answers=XXX
>The output log now will show correct cross-answers.
> third_party/waf/waflib/Context.py | 20 ++++++++++++++++++--
> third_party/waf/waflib/Tools/c_config.py | 11 +++++++----
> 2 files changed, 25 insertions(+), 6 deletions(-)
For third_party/waf https://gitlab.com/ita1024/waf is the master repository,
could you submit the changes there, so we can pull them from there later?
Can you think of a way to extend the samba-xc in script/autobuild.py
in order to trigger the problem?
That would be very useful as a future regression test.
Ok can confirm that the two patches work for samba 4.10.6 and it builds again for openwrt, yet i also needed the new patches from gentoo/Alpine(musl) for 4.10.
PS: Be aware that there is also a new bug "waf install --destdir=.. --targets=.." does not work anymore and will not install the build files into destdir.
Thomas would you be able to have a look at this waf related problems?
Propagating that "exec_args" argument to Context.py is highly questionable.
1. Since cross-compilation with a Qemu wrapper is uncommon, can you set the environment variable "export WAF_NO_PREFORK=1" before running such builds?
2. If it is impractical to set such environment variable before waf is launched, can you instead apply something similar to this to the sambas scripts?
3. Since the argument "args" is already added to the command, what is the point of adding it to exec_args again? Can you elaborate as to which rpath issues are fixed by the following and why?
- self.generator.bld.cmd_and_log([self.inputs.abspath()] + args, env=env)
+ self.generator.bld.cmd_and_log([self.inputs.abspath()] + args, env=env, exec_args=args)
4. You may redefine `class test_exec(Task.Task):` in the Samba scripts without changing the Waf files. If the Waf files should be changed, then at least one example should be provided *and* the test should be re-run when the arguments are modified (prevent accidental caching). Would `test_args` make a better name for such parameter?
5. Note: waf contributions are under this license https://gitlab.com/ita1024/waf/blob/master/waf-light#L5 (not the GPL), so Waf patches should be submitted to the Waf issue tracker, not here.
(In reply to Thomas Nagy from comment #7)
Thanks for the suggestions!
I’ll work on this problem soon.