bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13210: [PATCH] maint: cygwin build broken


From: Pádraig Brady
Subject: bug#13210: [PATCH] maint: cygwin build broken
Date: Mon, 17 Dec 2012 23:20:29 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]