Re: [bug-patch] major config problems with patch 2.6.1

[Andreas Gruenbacher]

On Monday 05 April 2010 17:09:21 Jim Reid wrote:
> Hi. There are a number of problems/errors compiling and 2.6.1 on BSD- 
> like platforms. It looks like patch has accidentally been turned into  
> something that only works on Linux. Sigh.

Patch currently includes its own copy of gnulib.  Unfortunately, a few things 
are broken; the most reasonable fix seems to be to switch to Automake and 
integrate gnulib like in diffutils.  I didn't get to that yet; patches would 
be welcome.

> [1] The generated Makefile contains lots of references to library  
> object modules like ${LIBOBJDIR}argmatch$U.o. This blows up when  
> there's an environment variable U which then gets appended into the  
> names of the build targets.

This should go away as part of switching to Automake.

> [2] The generated Makefile only works with gnu make. Older versions of  
> patch produced a vanilla Makefile that just worked with any flavour of  
> make.

Is this a big issue?

> [3] After fixing [1] by editing the Makefile, gnu make reports an  
> error "git: not found" on FreeBSD8.0, though patch still builds OK.

This must be in update-version.sh. What does this give?

        sh -x update-version.sh VERSION

> [4] On FreeBSD 7.2 linking fails:
> gcc: gl/lib/strnlen.o: No such file or directory
> gmake: *** [src/patch] Error 1
> Deleting this bogus target from the Makefile results in patch getting  
> built.

This should already be fixed the latest snapshot at 
http://alpha.gnu.org/gnu/patch/.

> [5] On MacOSX 10.5, linking doubly fails. The first is the same as  
> [4]. After deleting this spurious target, linking now fails:
> Undefined symbols:
>    "_rpl_strnlen", referenced from:
>        _strndup in strndup.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> gnumake: *** [src/patch] Error 1

This kind of explains that it's not a spurious target after all ...

> I've not yet kludged around this: the rat-hole of nested dependent  
> #ifdefs makes my head hurt.
> 
> [6] make check dies horribly if bash isn't installed. What's wrong  
> with a simple shell script?

It's supposed to work with a plain shell as well ... please send fixes ...

> [7] make check fails to work on BSD systems even when bash is  
> installed because the BSD mktemp requires a name/template for the  
> scratch directory or file, unlike the gnu one. Adding a sensible  
> argument like "/tmp/patch-$$" to tests/test-lib.sh
> solves that bug.

Okay, does the BSD version have -t?
Otherwise, would ${TMPDIR:-/tmp} work as a prefix?
Would patch.XXXXXXXXXX work as the path?

> [8] Some of the test scripts fail because seq is not installed. This  
> is remarkably dumb: why not just use "echo 1 2 3 4 5 > a" instead of  
> "seq 1 5 >a"?

Just send a remarkably smart patch.

> [9] The test scripts don't test the just-compiled patch! They will use  
> whatever patch is found first in the search path.

It does test the right patch binary for me; see use_local_patch() in 
tests/test-lib.sh.  Do you have the PATCH environment variable set?

> Perhaps these can be fixed in the next release?

Sure, it's not broken on purpose, I just didn't find the time to fix this 
properly, yet.  A good way of speeding things up would be to help ...

Thanks,
Andreas