[bug-diffutils] bug#24137: bug#24137: [platform-testers] new snapshot available: diffutils-3.3.57-a37c

[Jim Meyering]

On Fri, Aug 5, 2016 at 4:51 AM, Dagobert Michelsen <address@hidden> wrote:
> Hi Jim,
>
> Am 03.08.2016 um 21:51 schrieb Jim Meyering <address@hidden>:
>> On Wed, Aug 3, 2016 at 12:21 PM, Jim Meyering <address@hidden> wrote:
>>> On Wed, Aug 3, 2016 at 12:52 AM, Dagobert Michelsen <address@hidden> wrote:
>>>> Now I get on Solaris 10 x86:
>>>>
>>>>> gmake  check-TESTS
>>>>> gmake[1]: Entering directory 
>>>>> '/home/dam/mgar/pkg/diffutils/trunk/work/solaris10-i386/build-isa-pentium_pro/diffutils-3.3.57-a37c/tests'
>>>>> gmake[2]: Entering directory 
>>>>> '/home/dam/mgar/pkg/diffutils/trunk/work/solaris10-i386/build-isa-pentium_pro/diffutils-3.3.57-a37c/tests'
>>>>> diff: missing operand after `diff'
>>>>> diff: Try `diff --help' for more information.
>>>>> diff3: missing operand after `diff3'
>>>>> diff3: Try `diff3 --help' for more information.
>>>>> sdiff: missing operand after `sdiff'
>>>>> sdiff: Try `sdiff --help' for more information.
>>>>> /bin/sh: built_programs^Jdiff^Jdiff3^Jsdiff: is not an identifier
>>>
>>> I suspect that you are using an old version of GNU make.
>>> What if you use Solaris' make?
>
> I think it is GNU Make 4.1, but I’ll see that I get this updated to 4.2.1
>
>>> This patch should work around it, but then again, this patch should
>>> not be required, and I doubt I will have to resort to that approach.
>>
>> I forgot to attach that patch, but I didn't like it anyhow.
>> Here's one that I might actually apply.
>> Please let me know if it helps.
>> It is a bit contorted in attempt to keep the final "sed" invocation
>> portable by operating only on data with at least one trailing newline.
>
> Unfortunately I cannot bootstrap right now as my gettext is too old and I 
> haven’t finished
> an updated package yet, so I guess I’ll have to wait for the next 
> bootstrapped tarball.

Thanks for trying.
Please let me know the GNU make version: gmake --version should print it.
Also, you can apply that patch to the Makefile.in (not .am) file in
the latest pre-release tarball to test it without having to
re-bootstrap everything.
If I'm going to commit a work-around patch like that, I'd like to know
why (have to explain in the commit log, after all), and to be sure
that it is actually a fix. Notice how /bin/sh is mentioned in your
diagnostic. I wouldn't be surprised if it is involved.