Bug 13846 - cross-compile will not take cross-answers or cross-execute
cross-compile will not take cross-answers or cross-execute
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Build
All All
: P5 normal
: ---
Assigned To: Samba QA Contact
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2019-03-20 07:05 UTC by pinglin
Modified: 2019-07-29 05:43 UTC (History)
7 users (show)

See Also:

workaround for the issue (3.42 KB, patch)
2019-03-20 07:05 UTC, pinglin
no flags Details
fix rpath, related to the previous commit (1.08 KB, text/plain)
2019-04-03 02:23 UTC, pinglin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description pinglin 2019-03-20 07:05:20 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.

Build Date:
    after 4.10.0 rc
Comment 1 pinglin 2019-04-03 02:23:26 UTC
Created attachment 15040 [details]
fix rpath, related to the previous commit
Comment 2 Jeffery To 2019-06-08 07:31:25 UTC
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 3 Stefan Metzmacher 2019-06-12 10:32:26 UTC
Comment on attachment 14955 [details]
workaround for the issue

>From a197e0cafb276a9b732f914b1f679ebb487b47f1 Mon Sep 17 00:00:00 2001
>From: pinglin <pinglin@synology.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?

Comment 4 Stefan Metzmacher 2019-06-12 10:40:37 UTC
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.
Comment 5 andieq 2019-07-09 11:58:56 UTC
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.
Comment 6 Stefan Metzmacher 2019-07-09 16:06:25 UTC
Thomas would you be able to have a look at this waf related problems?

Comment 7 Thomas Nagy 2019-07-09 16:44:41 UTC
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[0].abspath()] + args, env=env)
+             self.generator.bld.cmd_and_log([self.inputs[0].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.
Comment 8 pinglin 2019-07-10 05:01:06 UTC
(In reply to Thomas Nagy from comment #7)
Thanks for the suggestions!
I’ll work on this problem soon.