FYI: pkg/43020

[YONETANI Tomokazu]

On Sat, Mar 27, 2010 at 05:43:35PM -0700, Matthew Dillon wrote:
> :If no one fixes pkg/43020 before the release, we'll have a semi-broken
> :git for x86_64:
> :
> :  http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=43020
> :
> :Apparently this mainly affects non-fast-forward merges or rebases
> :(but I'm not sure about some other rarely used commands), so people with
> :no local modifications are probably unaffected.
> 
>     Well, I'm not sure what to do here.  Are you talking about
>     all the implicit declaration warnings during the bmake ?

Yes.

>     We could enable all those prototypes for that _XOPEN_SOURCE
>     case I suppose.  It's the only thing I can think of.

The commit 716024cd2 has changed the visibility of some libc string
functions by moving them under __BSD_VISIBLE, so undoing that part
would do it.  But if I understand it correctly, the _*_SOURCE macros
are there to ensure some kind of portability including hiding some
non-standard functions, so re-exposing those functions seems backwards
to me.
If I read the git's change history correctly, the _XOPEN_SOURCE=600 was
first added to a .c file to cope with problems in OpenBSD and AIX, then
the macro definition was moved to git-compat-util.h later.  Other
BSD-variants seems to have suffered from it, including FreeBSD.  The fix
for FreeBSD, was in fact by not defining _XOPEN_SOURCE to 600.

The biggest problem in git source is that it defines those macros
which can affect the visibility of symbols in git-compat-util.h but
not during the configure script; so the script happily finds these
functions which end up undefined during compilation.

We could have LOCALPATCH to deal with a temporary breakage in pkgsrc
like this, but I don't know if it's the right direction to go.