On Fri, Aug 5, 2016 at 4:51 AM, Dagobert Michelsen <d...@opencsw.org> wrote: > Hi Jim, > > Am 03.08.2016 um 21:51 schrieb Jim Meyering <j...@meyering.net>: >> On Wed, Aug 3, 2016 at 12:21 PM, Jim Meyering <j...@meyering.net> wrote: >>> On Wed, Aug 3, 2016 at 12:52 AM, Dagobert Michelsen <d...@opencsw.org> >>> 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.
