bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS

[George Valkov]

> On 2023-03-21, at 8:21 PM, Pádraig Brady <P@draigBrady.com> wrote:
> 
> On 21/03/2023 18:08, George Valkov wrote:
>>> On 2023-03-21, at 7:32 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
>>> 
>>> On 3/21/23 08:27, George Valkov wrote:
>>>> However since the old m4-1.4.19 in under tools/m4, coreutils builds with 
>>>> the legacy version:
>>> 
>>> If you're building from that tarball, coreutils doesn't need m4. I just now 
>>> double-checked that, in an environment that didn't have m4. "./configure && 
>>> make check" succeeded. So the m4 version should be irrelevant.
>> Yes, I can confirm that a stand-alone build using your instructions works. I 
>> do not have enough experience with the OpenWRT build system, but what I can 
>> see is that at some point it tries to run staging_dir/host/bin/m4
>> And that’s why I had the impression that the legacy version of m4 is used. I 
>> might be wrong, and maybe it just needs that executable, since when tools/m4 
>> is present, tools/coreutils builds and works. If the m4 directory from the 
>> tarball is used, then everything’s fine, we can keep tools/m4 as it is.
>> staging_dir/host/bin/m4 is compiled from tools/m4 and does not exist without 
>> tools/m4, so the build fails if I remove it. If I create a link to 
>> /usr/local/Cellar/m4/1.4.19/bin/m4, that part of the build succeeds, but 
>> then we also need to apply the following patch:
>> https://github.com/openwrt/openwrt/blob/master/tools/coreutils/patches/001-m4.patch
>> Do you know if the patch is applied upstream in coreutils?
> 
> Yes if that m4 file is patched then m4 will need to run to regen stuff.
> Though the existing m4 tool should be fine for that.
> I would look at figuring out why that m4 tool is not available in your env.
> Perhaps you need to define an M4 env variable or something.
> 
> The openwrt m4 patch originates from
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=c5608227
> and that pattern seems to have originated from:
> https://github.com/openwrt/packages/issues/14120#issuecomment-749438742
> For the patch not to be needed it would need to be applied to gnulib,
> but I don't know how general it is.

Thanks, Pádraig!

The OpenWRT build system is designed to work on many platforms. To achieve 
this, some helper host tools are compiled and used later. These tools are 
installed in staging_dir/host/bin, and they are used during the build instead 
of whatever is installed on the system. On macOS for example the default 
version of m4 is old and does not support the --gnu switch, so it is not 
suitable for the build. Hence OpenWRT compiles a working version and uses it 
during the build.

Without the patch, the OpenWRT tools/coreutils build fails. Build log:
https://httpstorm.com/share/.openwrt/test/2023-02-06_coreutils-9.1/2023-03-21-openwrt-build-coreutils-9.2-no-patch.txt

With the patch it builds correctly. The target cross-platform build for 
coreutils does not use the patch and builds correctly. A regular build outside 
of OpenWRT also does not need the patch. This seems like improperly configured 
include search path or environment on OpenWRT side. So I guess it would be best 
if we can fix that and go without the patch.

At this point I believe that toos/m4 is only used to produce the executable, 
and so it does not require any changes since the m4 directory that comes with 
coreutils is used.


Cheers mate!

Georgi Valkov
httpstorm.com
nano RTOS