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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13210 in the body.
You can then email your comments to 13210 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "Z. Majeed" <zmajeed <at> sbcglobal.net>
To: bug-coreutils <at> gnu.org
Subject: [PATCH] maint: cygwin build broken
Date: Mon, 17 Dec 2012 03:50:22 -0800 (PST)

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

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)

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

Zartaj

diff --git a/doc/local.mk b/doc/local.mk
old mode 100644
new mode 100755
index 585faf0..63696fb
--- a/doc/local.mk
+++ b/doc/local.mk
@@ -34,7 +34,7 @@ doc_coreutils_TEXINFOS = \
 # old systems.
 AM_MAKEINFOFLAGS = --no-split

-doc/constants.texi: $(top_srcdir)/src/tail.c $(top_srcdir)/src/shred.c
+doc/constants.texi: $(top_srcdir)/src/tail.c $(top_srcdir)/src/shred.c doc/$(am__dirstamp)
        $(AM_V_GEN)LC_ALL=C; export LC_ALL; \
        { sed -n -e 's/^#define \(DEFAULT_MAX[_A-Z]*\) \(.*\)/@set \1 \2/p' \
            $(top_srcdir)/src/tail.c && \
diff --git a/gnulib b/gnulib
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit d245e6ddd6ab2624d0d83acd8f111454f984f50f
+Subproject commit d245e6ddd6ab2624d0d83acd8f111454f984f50f-dirty
diff --git a/src/local.mk b/src/local.mk
old mode 100644
new mode 100755
index ead3b8b..66028c9
--- a/src/local.mk
+++ b/src/local.mk
@@ -387,9 +387,9 @@ src/dircolors.h: src/dcgen src/dircolors.hin
 # known ints (currently 128-bit).
 BUILT_SOURCES += $(top_srcdir)/src/primes.h
 $(top_srcdir)/src/primes.h:
-       $(MAKE) src/make-prime-list
+       $(MAKE) src/make-prime-list$(EXEEXT)
        $(AM_V_GEN)rm -f $@ $@-t
-       $(AM_V_at)src/make-prime-list 5000 > $@-t
+       $(AM_V_at)src/make-prime-list$(EXEEXT) 5000 > $@-t
        $(AM_V_at)chmod a-w $@-t
        $(AM_V_at)mv $@-t $@

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.

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

From: "Z. Majeed" <zmajeed <at> sbcglobal.net>
To: Pádraig Brady <P <at> draigBrady.com>
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 18:57:53 -0800 (PST)

You're probably right about the mkdir doc hack - I think I added it based on a similar rule for another subdir - the win7 elevation requirement is discussed at length at http://social.msdn.microsoft.com/forums/en-US/windowssecurity/thread/73f86e9e-928f-40b7-8dd5-27e40db6997e/ - the upshot is ginstall.exe needs a manifest to be exempt from win7 racial profiling - the cygwin folks must have a manifest when creating a coreutils package - the latest on cygwin is coreutils 8.15

Zartaj

--- On Mon, 12/17/12, Pádraig Brady <P <at> draigBrady.com> wrote:

> From: Pádraig Brady <P <at> draigBrady.com>
> Subject: Re: bug#13210: [PATCH] maint: cygwin build broken
> 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.
>

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

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

On 12/18/2012 02:57 AM, Z. Majeed wrote:
> --- On Mon, 12/17/12, Pádraig Brady <P <at> draigBrady.com> wrote:
>
>> From: Pádraig Brady <P <at> draigBrady.com>
>> Subject: Re: bug#13210: [PATCH] maint: cygwin build broken
>> 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.

> You're probably right about the mkdir doc hack - I think I added it based on a similar rule for another subdir

Zartaj also mentioned to me he's using automake 1.12.5 and autoconf 2.69

thanks,
Pádraig.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 13210 <at> debbugs.gnu.org, "Z. Majeed" <zmajeed <at> sbcglobal.net>
Subject: Re: bug#13210: [PATCH] maint: cygwin build broken
Date: Tue, 18 Dec 2012 09:58:48 +0100

On 12/18/2012 12:20 AM, Pádraig Brady wrote:
> 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
>
Nope, that change had been later reverted, before any stable release:
<http://git.sv.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.11-512-g40c3432>

> 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)
>         ...
>
This rules is there also for makefiles generated by Automake 1.12.x.

And the issue here is really not Automake's fault; the problem really likes in
the coreutil's build system, since the declaration:

   doc/constants.texi: $(top_srcdir)/src/tail.c $(top_srcdir)/src/shred.c

is hand-written in 'doc/local.mk', and is not provided by Automake.

So what suggested by the OP is not a workaround, but a fix -- and it
seems a correct fix to me (albeit a little abusing of Automake's
internal).

> BTW, Steffano, how can I see what release the above commit
> is included in?
>
No one :-)

> Only minor versions seem to be tagged?
>
How so?  I see:
<http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.12>

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

HTH,
  Stefano

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

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

On 12/18/2012 08:58 AM, Stefano Lattarini wrote:
> On 12/18/2012 12:20 AM, Pádraig Brady wrote:
>> 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
>>
> Nope, that change had been later reverted, before any stable release:
> <http://git.sv.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.11-512-g40c3432>
>
>> 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)
>>          ...
>>
> This rules is there also for makefiles generated by Automake 1.12.x.
>
> And the issue here is really not Automake's fault; the problem really likes in
> the coreutil's build system, since the declaration:
>
>     doc/constants.texi: $(top_srcdir)/src/tail.c $(top_srcdir)/src/shred.c
>
> is hand-written in 'doc/local.mk', and is not provided by Automake.
>
> So what suggested by the OP is not a workaround, but a fix -- and it
> seems a correct fix to me (albeit a little abusing of Automake's
> internal).

I misread the above rule last night, and thought Zartaj's fix
to a broken coreutils.info build was to piggy back on the
working constants.texi build. In general it's best to send
error messages along with a patch like this so that reviewers
can follow the same train of thought.

Anyway an explicit `make doc/constants.texi` fails on my system too
(with a non-src build), and so can fail in a larger build
due to ordering of rules.

Since we're manually writing the doc/constants.texi rule anyway,
I prefer to just add in the MKDIR_P which is the technique we
use elsewhere in coreutils.

>
>> BTW, Steffano, how can I see what release the above commit
>> is included in?
>>
> No one :-)
>
>> Only minor versions seem to be tagged?
>>
> How so?  I see:
> <http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.12>

I was looking for a tag at each release. 1.11.6 etc.
They weren't done for the 1.11 series but they are in place
since 1.12, for example:
http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.12.5
There's probably little need to retag older releases,
so it's fine going forward.

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

Thanks a lot for looking at this, and sorry for misreading
the rule last night, I shouldn't have bothered you at all,
with this now obvious issue.

It's good to know we could rely on am__dirstamp in future if needed.

Zartaj I'll apply the following in your name soon.

thanks!
Pádraig.

commit 860307bde02e12700e8a08daf3536801e86e8da8
Author: Zartaj Majeed <zmajeed <at> sbcglobal.net>
Date:   Tue Dec 18 09:50:50 2012 +0000

    build: fix cygwin build issues

    * doc/local.mk (doc/constants.texi): Ensure the doc directory
    is present which is needed when doing a non source dir build,
    when the doc/constants.texi target is built before other doc targets.
    * src/local.mk: Add $(EXEEXT) to the make-prime-list calls.

diff --git a/doc/local.mk b/doc/local.mk
index 585faf0..ad25528 100644
--- a/doc/local.mk
+++ b/doc/local.mk
@@ -36,6 +36,7 @@ AM_MAKEINFOFLAGS = --no-split

 doc/constants.texi: $(top_srcdir)/src/tail.c $(top_srcdir)/src/shred.c
        $(AM_V_GEN)LC_ALL=C; export LC_ALL; \
+       $(MKDIR_P) doc && \
        { sed -n -e 's/^#define \(DEFAULT_MAX[_A-Z]*\) \(.*\)/@set \1 \2/p' \
            $(top_srcdir)/src/tail.c && \
          sed -n -e \
diff --git a/src/local.mk b/src/local.mk
index ead3b8b..66028c9 100644
--- a/src/local.mk
+++ b/src/local.mk
@@ -387,9 +387,9 @@ src/dircolors.h: src/dcgen src/dircolors.hin
 # known ints (currently 128-bit).
 BUILT_SOURCES += $(top_srcdir)/src/primes.h
 $(top_srcdir)/src/primes.h:
-       $(MAKE) src/make-prime-list
+       $(MAKE) src/make-prime-list$(EXEEXT)
        $(AM_V_GEN)rm -f $@ $@-t
-       $(AM_V_at)src/make-prime-list 5000 > $@-t
+       $(AM_V_at)src/make-prime-list$(EXEEXT) 5000 > $@-t
        $(AM_V_at)chmod a-w $@-t
        $(AM_V_at)mv $@-t $@

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 13210-done <at> debbugs.gnu.org, "Z. Majeed" <zmajeed <at> sbcglobal.net>
Subject: Re: bug#13210: [PATCH] maint: cygwin build broken
Date: Tue, 18 Dec 2012 11:30:19 +0100

On 12/18/2012 11:20 AM, Pádraig Brady wrote:
>
> [SNIP]
>
> Anyway an explicit `make doc/constants.texi` fails on my system too
> (with a non-src build), and so can fail in a larger build
> due to ordering of rules.
> 
> Since we're manually writing the doc/constants.texi rule anyway,
> I prefer to just add in the MKDIR_P which is the technique we
> use elsewhere in coreutils.
>
Yeah, but is a simpler and safer idiom.

>>> Only minor versions seem to be tagged?
>>>
>> How so?  I see:
>> <http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.12>
> 
> I was looking for a tag at each release. 1.11.6 etc.
>
<http://git.savannah.gnu.org/cgit/automake.git/tag/?id=v1.11.6>
<http://git.savannah.gnu.org/cgit/automake.git/tag/?id=v1.11.5>
<http://git.savannah.gnu.org/cgit/automake.git/tag/?id=v1.11.4>

etc ;-)

> They weren't done for the 1.11 series but they are in place
> since 1.12, for example:
> http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.12.5
> There's probably little need to retag older releases,
> so it's fine going forward.
> 

> [SNIP]

> It's good to know we could rely on am__dirstamp in future if needed.
>
Actually, that is an automake internal (as hinted by the 'am__'
prefix), and should not be relied upon if at all possible (like
it was in this case).

Best regards, and HTH,
  Stefano

Message #28 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
Subject: Re: bug#13210: [PATCH] maint: cygwin build broken
Date: Wed, 19 Dec 2012 10:23:55 +0000

[Message part 1 (text/plain, inline)]

On 12/17/2012 11:20 PM, Pádraig Brady wrote:
> 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

>> 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.

It could be avoided in gnulib as detailed here:
http://lists.gnu.org/archive/html/bug-gnulib/2012-12/msg00087.html

But I think the attached coreutils patch
which just avoids auto enabling all these gcc
warnings on older compilers is more appropriate.

thanks,
Pádraig.

[gcc-4.5-warnings.diff (text/x-patch, attachment)]

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

From: "Z. Majeed" <zmajeed <at> sbcglobal.net>
To: 13210 <at> debbugs.gnu.org
Cc: ZartajPrivate <zmajeed <at> sbcglobal.net>
Subject: Re: bug#13210: [PATCH] maint: cygwin build broken
Date: Wed, 19 Dec 2012 04:57:02 -0800 (PST)

Thanks for fixing all the issues - are you folks open to adding a ginstall.exe manifest for the cygwin build?

Zartaj

--- On Mon, 12/17/12, Z. Majeed <zmajeed <at> sbcglobal.net> wrote:

> You're probably right about the mkdir
> doc hack - I think I added it based on a similar rule for
> another subdir - the win7 elevation requirement is discussed
> at length at http://social.msdn.microsoft.com/forums/en-US/windowssecurity/thread/73f86e9e-928f-40b7-8dd5-27e40db6997e/
> - the upshot is ginstall.exe needs a manifest to be exempt
> from win7 racial profiling - the cygwin folks must have a
> manifest when creating a coreutils package - the latest on
> cygwin is coreutils 8.15
> 
> Zartaj
> 
> --- On Mon, 12/17/12, Pádraig Brady <P <at> draigBrady.com>
> wrote:
> 
> > 
> > > 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.
> >
>

Message #34 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, Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#13210: [PATCH] maint: cygwin build broken
Date: Wed, 19 Dec 2012 13:25:33 +0000

On 12/19/2012 12:57 PM, Z. Majeed wrote:
> Thanks for fixing all the issues - are you folks open to adding a ginstall.exe manifest for the cygwin build?

I presume the cygwin package puts one in place,
and it would be nice to keep windows specific stuff there.
There is a related thread here:
http://cygwin.com/ml/cygwin/2012-07/msg00293.html

thanks,
Pádraig.

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

From: Eric Blake <eblake <at> redhat.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 13210 <at> debbugs.gnu.org, "Z. Majeed" <zmajeed <at> sbcglobal.net>
Subject: Re: bug#13210: [PATCH] maint: cygwin build broken
Date: Wed, 19 Dec 2012 08:28:43 -0700

[Message part 1 (text/plain, inline)]

On 12/19/2012 06:25 AM, Pádraig Brady wrote:
> On 12/19/2012 12:57 PM, Z. Majeed wrote:
>> Thanks for fixing all the issues - are you folks open to adding a
>> ginstall.exe manifest for the cygwin build?
> 
> I presume the cygwin package puts one in place,
> and it would be nice to keep windows specific stuff there.
> There is a related thread here:
> http://cygwin.com/ml/cygwin/2012-07/msg00293.html

Correct - when I build coreutils for the cygwin distro, the manifest
file is built as part of the cygwin-specific patches that I apply.  I'm
not sure whether it makes sense to try and upstream something that is so
platform specific; on the one hand, it would make out-of-the-box
development on cygwin easier; on the other hand, we don't have too many
people doing out-of-the-box development (most people rely on the
pre-built coreutils in the cygwin distro).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

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

From: Eric Blake <eblake <at> redhat.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 13210 <at> debbugs.gnu.org, "Z. Majeed" <zmajeed <at> sbcglobal.net>
Subject: Re: bug#13210: [PATCH] maint: cygwin build broken
Date: Wed, 19 Dec 2012 08:29:45 -0700

[Message part 1 (text/plain, inline)]

On 12/19/2012 03:23 AM, Pádraig Brady wrote:
> 
> But I think the attached coreutils patch
> which just avoids auto enabling all these gcc
> warnings on older compilers is more appropriate.

I like the idea of only enabling the warnings on newer gcc.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

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

From: "Z. Majeed" <zmajeed <at> sbcglobal.net>
To: 13210 <at> debbugs.gnu.org
Cc: ZartajPrivate <zmajeed <at> sbcglobal.net>
Subject: Re: bug#13210: [PATCH] maint: cygwin build broken
Date: Wed, 19 Dec 2012 07:46:15 -0800 (PST)

or maybe there aren't many people building on cygwin because of issues like the ones I reported - cygwin packages can fall quite behind and coreutils is not available on cygwinports either - I know I was close to giving up and just working on linux

Zartaj

--- On Wed, 12/19/12, Eric Blake <eblake <at> redhat.com> wrote:
> 
> On 12/19/2012 06:25 AM, Pádraig
> Brady wrote:
> > On 12/19/2012 12:57 PM, Z. Majeed wrote:
> >> Thanks for fixing all the issues - are you folks
> open to adding a
> >> ginstall.exe manifest for the cygwin build?
> > 
> > I presume the cygwin package puts one in place,
> > and it would be nice to keep windows specific stuff
> there.
> > There is a related thread here:
> > http://cygwin.com/ml/cygwin/2012-07/msg00293.html
> 
> Correct - when I build coreutils for the cygwin distro, the
> manifest
> file is built as part of the cygwin-specific patches that I
> apply.  I'm
> not sure whether it makes sense to try and upstream
> something that is so
> platform specific; on the one hand, it would make
> out-of-the-box
> development on cygwin easier; on the other hand, we don't
> have too many
> people doing out-of-the-box development (most people rely on
> the
> pre-built coreutils in the cygwin distro).
> 
> -- 
> Eric Blake   eblake redhat com   
> +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 
>

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "Z. Majeed" <zmajeed <at> sbcglobal.net>
Cc: 13210 <at> debbugs.gnu.org
Subject: Re: bug#13210: [PATCH] maint: cygwin build broken
Date: Wed, 19 Dec 2012 07:49:01 -0800

On 12/19/2012 07:46 AM, Z. Majeed wrote:
> I know I was close to giving up and just working on linux

That's not giving up!

Previous Next

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