GNU bug report logs - #13210
[PATCH] maint: cygwin build broken

Previous Next

Full log

Message #8 received at 13210 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: "Z. Majeed" <zmajeed <at> sbcglobal.net>
Cc: 13210 <at> debbugs.gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com>
Subject: Re: bug#13210: [PATCH] maint: cygwin build broken
Date: Mon, 17 Dec 2012 23:20:29 +0000

On 12/17/2012 11:50 AM, Z. Majeed wrote:
> Building latest git source in a non-src directory on cygwin win7 with gcc 4.5.3 is broken - a patch follows -
> doc/local.mk: doc subdir is not created in build dir - I made it a prereq of doc/constants.texi

That seems a little hacky, for what seems like an automake bug.
Maybe this one is the culprit?
http://git.sv.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.11-328-ge87c030
I use automake-1.11.6 and the coreutils configured min version is 1.11.2.
Specifically I'm not impacted as I have this in Makefile:

$(srcdir)/doc/version.texi:  $(srcdir)/doc/stamp-vti
$(srcdir)/doc/stamp-vti: doc/coreutils.texi $(top_srcdir)/configure
        test -f doc/$(am__dirstamp) || $(MAKE) $(AM_MAKEFLAGS) doc/$(am__dirstamp)
        ...

BTW, Steffano, how can I see what release the above commit
is included in? Only minor versions seem to be tagged?

I dislike dependency creep so am open to a workaround
as long as we know what's going on.

> - src/local.mk: make-prime-list missing $(EXEEXT) couple of places without which make-prime-list.exe does not build

Good one, I'll include that.

> I had to configure --disable-gcc-warnings to avoid the following errors because gcc 4.5.3 is the latest on cygwin
> and not covered by the ignore warnings pragma in extern-inline.m4 for gcc 4.6 and higher:
>    CC       dtotimespec.o
> In file included from dtotimespec.c:25:0:
> timespec.h:58:1: error: no previous declaration for 'timespec_cmp'
> [-Werror=missing-declarations]
>   timespec_cmp (struct timespec a, struct timespec b)

That's a possible gnulib issue. I'll CC there separately.

> On win7 running ginstall for man/install.1 build required admin rights

Surprising. ginstall --help shouldn't need admin privs.
I'm not in a position to test windows though, sorry.
Perhaps you could trace the call requiring admin rights?

thanks,
Pádraig.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.