GCC-4.7.2-2: Go/No-go?

GCC-4.7.2-2: Go/No-go?

[Dave Korn]

    Hi all,

  I have a release of 4.7.2-2 ready to upload.  It fixes the dependencies back
to the 4.5.3-3 curr: version dependencies, makes TLS vars exported from DLLs
work and restores java and libffi.  I've also been running the testsuite over
the last few days and the results look quite reasonable.

  Yaakov thinks (http://cygwin.com/ml/cygwin-apps/2013-04/msg00032.html) that
I shouldn't release it until I've integrated all his patches.

  I think (http://cygwin.com/ml/cygwin-apps/2013-04/msg00057.html) that it's
worth uploading as a stop-gap to address the mentioned problems and
integrating Yaakov's patches for the next release.

  Could the list please help us make a decision?

    cheers,
      DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Corinna Vinschen]

On Apr  9 17:17, Dave Korn wrote:
> 
>     Hi all,
> 
>   I have a release of 4.7.2-2 ready to upload.  It fixes the dependencies back
> to the 4.5.3-3 curr: version dependencies, makes TLS vars exported from DLLs
> work and restores java and libffi.  I've also been running the testsuite over
> the last few days and the results look quite reasonable.
> 
>   Yaakov thinks (http://cygwin.com/ml/cygwin-apps/2013-04/msg00032.html) that
> I shouldn't release it until I've integrated all his patches.
> 
>   I think (http://cygwin.com/ml/cygwin-apps/2013-04/msg00057.html) that it's
> worth uploading as a stop-gap to address the mentioned problems and
> integrating Yaakov's patches for the next release.
> 
>   Could the list please help us make a decision?

I'd prefer if we could get 4.7.2 into the distro rather sooner than
later.  As long as it is a test release, it doesn't matter much if all
patches are in.

For the first "real" release it would be better to have them, if they
are necessary, though.  How far away are we from there?

And while we're at it, what about reviewing Achim's gmp/mpfr/mpclib/
ppl/cloog-ppl packages?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: GCC-4.7.2-2: Go/No-go?

[Achim Gratz]

Dave Korn writes:
>   I have a release of 4.7.2-2 ready to upload.  It fixes the dependencies back
> to the 4.5.3-3 curr: version dependencies, makes TLS vars exported from DLLs
> work and restores java and libffi.  I've also been running the testsuite over
> the last few days and the results look quite reasonable.
>
>   Yaakov thinks (http://cygwin.com/ml/cygwin-apps/2013-04/msg00032.html) that
> I shouldn't release it until I've integrated all his patches.
>
>   I think (http://cygwin.com/ml/cygwin-apps/2013-04/msg00057.html) that it's
> worth uploading as a stop-gap to address the mentioned problems and
> integrating Yaakov's patches for the next release.

To me it sounds like it should be released to get the recompiles going,
but then I don't really know what exactly is in the patches Yaakov were
talking about and if maybe they'd trigger another round of rebuilds.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: GCC-4.7.2-2: Go/No-go?

[Christopher Faylor]

On Wed, Apr 10, 2013 at 05:31:55PM +0200, Achim Gratz wrote:
>Dave Korn writes:
>>   I have a release of 4.7.2-2 ready to upload.  It fixes the dependencies back
>> to the 4.5.3-3 curr: version dependencies, makes TLS vars exported from DLLs
>> work and restores java and libffi.  I've also been running the testsuite over
>> the last few days and the results look quite reasonable.
>>
>>   Yaakov thinks (http://cygwin.com/ml/cygwin-apps/2013-04/msg00032.html) that
>> I shouldn't release it until I've integrated all his patches.
>>
>>   I think (http://cygwin.com/ml/cygwin-apps/2013-04/msg00057.html) that it's
>> worth uploading as a stop-gap to address the mentioned problems and
>> integrating Yaakov's patches for the next release.
>
>To me it sounds like it should be released to get the recompiles going,
>but then I don't really know what exactly is in the patches Yaakov were
>talking about and if maybe they'd trigger another round of rebuilds.

It isn't clear to me why we'd be spending days discussing this when
presumably the patches apply without too much effort.  Some of the
patches here:

http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc

look worthwhile to me.  If we're talking about only gcc 4.7 fixes then
it looks like we're only talking about five patches, none of them are to
source files, and none of them are very big.

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 10/04/2013 16:47, Christopher Faylor wrote:

> It isn't clear to me why we'd be spending days discussing this when
> presumably the patches apply without too much effort.  Some of the
> patches here:
> 
> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc
> 
> look worthwhile to me.  If we're talking about only gcc 4.7 fixes then
> it looks like we're only talking about five patches, none of them are to
> source files, and none of them are very big.

  It takes 11 hours on a triple-core machine at -j6 to build and package GCC.
 In order to guarantee consistent reproduction I always respin the built
package from -src package through two generations.  It then takes three to
five days to run enough of the testsuite to be confident that the packaged
compiler works well.  So it'd be next week at the earliest.

  Hence I'm uploading 4.7.2-2 now.

    cheers,
      DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Yaakov (Cygwin/X)]

On 2013-04-10 11:56, Dave Korn wrote:
>    It takes 11 hours on a triple-core machine at -j6 to build and package GCC.
>   In order to guarantee consistent reproduction I always respin the built
> package from -src package through two generations.  It then takes three to
> five days to run enough of the testsuite to be confident that the packaged
> compiler works well.  So it'd be next week at the earliest.

While your diligence is admirable, I think some common sense review can 
be used here, as only one of my patches actually affects the compiler 
itself, and even then only the specs.  I'm not exactly messing around 
with code generation here.

BTW, in your absence, it was agreed that gcc3 should go away and that 
gcc4 should be *the* gcc in the distro.  This will simplify the build 
and drop the dep on 'alternatives'.  Can this get into the next release?

I don't understand why there's a libquadmath0-devel; like the other C 
libraries, this should just be part of gcc-core.  This was only 
necessary for libstdc++, and only so long as .la files were included. 
IIRC we agreed to remove them, but your reason for not doing so in the 
.cygport isn't clear to me.

Also, could you please explain the reasons for the ehdebug, execstack, 
and shared-libgcc patches?


Yaakov

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 11/04/2013 03:23, Yaakov (Cygwin/X) wrote:
> On 2013-04-10 11:56, Dave Korn wrote:
>>    It takes 11 hours on a triple-core machine at -j6 to build and
>> package GCC.
>>   In order to guarantee consistent reproduction I always respin the built
>> package from -src package through two generations.  It then takes
>> three to
>> five days to run enough of the testsuite to be confident that the
>> packaged
>> compiler works well.  So it'd be next week at the earliest.
> 
> While your diligence is admirable, I think some common sense review can
> be used here, as only one of my patches actually affects the compiler
> itself, and even then only the specs.  I'm not exactly messing around
> with code generation here.

  Yes, I've looked at most of your patches already, I'm not saying there's any
complication in adding them, it's just that I didn't want to wait another
howevermany days before getting 4.7.2-2 out there.  I'll put them all into the
next release, which I'll get on with pronto.

> BTW, in your absence, it was agreed that gcc3 should go away and that
> gcc4 should be *the* gcc in the distro.  This will simplify the build
> and drop the dep on 'alternatives'.  Can this get into the next release?

  Yep, sure.  *sigh*, I'm sure we'll suddenly find out that someone was using
it and wants to know where it's gone.  (I suppose if that happens I could
always consider rolling a gcc3 package with all -3 suffixed executables.)

  I'll need to make sure not to lose the cc.exe -> gcc.exe symlink, and it
might be useful for backward-compatibility to provide a bunch of -4 suffixed
links to the other executables for people who've written CC=gcc-4 in their
Makefiles, but that can be done with just ln rather than using alternatives.

> I don't understand why there's a libquadmath0-devel; like the other C
> libraries, this should just be part of gcc-core.  

  Hmm.  I got the impression that libquadmath could stand alone, i.e. be
useful in a non-GCC context, but I guess not or it would be installing its
include files into /usr/include rather than the GCC private include dir.  I'll
merge it into gcc-core in the next release as you suggest.

> This was only
> necessary for libstdc++, and only so long as .la files were included.
> IIRC we agreed to remove them, but your reason for not doing so in the
> .cygport isn't clear to me.

  Without the .la files, libjava doesn't build.  And in general I don't want
to second-guess the compiler: since the upstream makefiles think it's
important to install them, so do I.

> Also, could you please explain the reasons for the ehdebug, execstack,
> and shared-libgcc patches?

  ehdebug: When we first switched from sjlj to dw2 exceptions, there were so
many corner case bugs that kept cropping up across multiple releases that I
wanted to hang onto the debugging code.  During development the debugging
output was under control of a variable that I replaced by a #define 0 just
before the release.  It's obsolete now, I'll drop it, but it was incredibly
useful for the first few gcc4 releases.

  execstack: Trampolines need an executable stack.  DEP on recent Windows OSs
marks the stack non-executable; this option allows the stack to be set
executable during the runtime startup, without having to disable DEP for the
entire process.  Think I may have inherited it from Danny Smith.  Mingw has it
upstream, I'll get it committed there for Cygwin too.

  shared-libgcc: Makes linking against shared libgcc the default for all
executables; previously it was only on by default for DLLs.  Vital for
importing TLS variables from DLLs, upstream since 4.8.0.

    cheers,
      DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Yaakov (Cygwin/X)]

On 2013-04-11 01:02, Dave Korn wrote:
>    Yes, I've looked at most of your patches already, I'm not saying there's any
> complication in adding them, it's just that I didn't want to wait another
> howevermany days before getting 4.7.2-2 out there.  I'll put them all into the
> next release, which I'll get on with pronto.

Your boehm-gc patch can replace my java-libgc-win32.patch, provided it 
works properly.

libitm needs some more work before enabling, at least on x86_64 due to 
weak symbol and sysv_abi assumptions (I have managed to get 
statically-linked executables to work, but not DLL-linked ones); on i686 
it *might* actually work with just my patch (the one in 4.8 branch is 
better), but in the interest of time this should probably wait for a 
future release.

Also in the 4.8 branch is a patch to unversion the LTO plugin; it 
applies to 4.7 as well.

Something else you missed: cygport supports a new, unversioned file 
format, and creates setup.hint files, including dependency detection.  I 
suggest using git master right now.

>    Yep, sure.  *sigh*, I'm sure we'll suddenly find out that someone was using
> it and wants to know where it's gone.  (I suppose if that happens I could
> always consider rolling a gcc3 package with all -3 suffixed executables.)

3.4 is EOL and should have been dropped long ago; we simply don't have 
the resources to support it ourselves.  Just about any software that 
people are building today either works with recent 4.x or the distros 
have a patch for it.

>    I'll need to make sure not to lose the cc.exe -> gcc.exe symlink, and it
> might be useful for backward-compatibility to provide a bunch of -4 suffixed
> links to the other executables for people who've written CC=gcc-4 in their
> Makefiles, but that can be done with just ln rather than using alternatives.

That was never right, CC isn't supposed to be (ab)used like that.  I 
don't mind not supporting that going forward.

>    Without the .la files, libjava doesn't build.   And in general I don't want
> to second-guess the compiler: since the upstream makefiles think it's
> important to install them, so do I.

How could removing the .la files during postinstall affect building 
libjava beforehand?

As for the makefiles installing the .la files, upstream isn't "choosing" 
to do so, that's just how libtool works.  Some Linux distros, including 
Fedora, have been removing them from all binary packages (except when 
they are needed by lt_dlopen() and friends), and for very good reason.

>    execstack: Trampolines need an executable stack.  DEP on recent Windows OSs
> marks the stack non-executable; this option allows the stack to be set
> executable during the runtime startup, without having to disable DEP for the
> entire process.  Think I may have inherited it from Danny Smith.  Mingw has it
> upstream, I'll get it committed there for Cygwin too.

Should this be used on x86_64 as well?  The libgcc/config.host hunk of 
your patch only mentions ix86.

>    shared-libgcc: Makes linking against shared libgcc the default for all
> executables; previously it was only on by default for DLLs.  Vital for
> importing TLS variables from DLLs, upstream since 4.8.0.

Here we go again...



Yaakov

Re: GCC-4.7.2-2: Go/No-go?

[Corinna Vinschen]

On Apr 11 01:58, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 01:02, Dave Korn wrote:
> >   Yep, sure.  *sigh*, I'm sure we'll suddenly find out that someone was using
> >it and wants to know where it's gone.  (I suppose if that happens I could
> >always consider rolling a gcc3 package with all -3 suffixed executables.)
> 
> 3.4 is EOL and should have been dropped long ago; we simply don't
> have the resources to support it ourselves.  Just about any software
> that people are building today either works with recent 4.x or the
> distros have a patch for it.

FWIW, I agree.


AOL-Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 11/04/2013 11:13, Corinna Vinschen wrote:
> On Apr 11 01:58, Yaakov (Cygwin/X) wrote:
>> On 2013-04-11 01:02, Dave Korn wrote:
>>>   Yep, sure.  *sigh*, I'm sure we'll suddenly find out that someone was using
>>> it and wants to know where it's gone.  (I suppose if that happens I could
>>> always consider rolling a gcc3 package with all -3 suffixed executables.)
>> 3.4 is EOL and should have been dropped long ago; we simply don't
>> have the resources to support it ourselves.  Just about any software
>> that people are building today either works with recent 4.x or the
>> distros have a patch for it.
> 
> FWIW, I agree.
> 
> 
> AOL-Corinna

  I said I could consider it, I didn't say I was necessarily going to do it :)

  Still, you'd be surprised the number of questions I see on random websites
(stackoverflow, linuxquestions and similar) where someone's asking how to
install an old GCC to build some old software.

    cheers,
      DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Corinna Vinschen]

On Apr 11 13:14, Dave Korn wrote:
> On 11/04/2013 11:13, Corinna Vinschen wrote:
> > On Apr 11 01:58, Yaakov (Cygwin/X) wrote:
> >> On 2013-04-11 01:02, Dave Korn wrote:
> >>>   Yep, sure.  *sigh*, I'm sure we'll suddenly find out that someone was using
> >>> it and wants to know where it's gone.  (I suppose if that happens I could
> >>> always consider rolling a gcc3 package with all -3 suffixed executables.)
> >> 3.4 is EOL and should have been dropped long ago; we simply don't
> >> have the resources to support it ourselves.  Just about any software
> >> that people are building today either works with recent 4.x or the
> >> distros have a patch for it.
> > 
> > FWIW, I agree.
> > 
> > 
> > AOL-Corinna
> 
>   I said I could consider it, I didn't say I was necessarily going to do it :)
> 
>   Still, you'd be surprised the number of questions I see on random websites
> (stackoverflow, linuxquestions and similar) where someone's asking how to
> install an old GCC to build some old software.

So what?  It's definitely wrong that our "gcc" package installs an old
gcc, rather than a recent one.  If you really want to stick to an old
gcc, make sure it's not the default.  Call it gcc-3 or legacy-gcc, but
let's get it out of the way of the most recent version.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: GCC-4.7.2-2: Go/No-go?

[NightStrike]

On Thu, Apr 11, 2013 at 2:19 AM, Corinna Vinschen wrote:
> On Apr 11 13:14, Dave Korn wrote:
>> On 11/04/2013 11:13, Corinna Vinschen wrote:
>> > On Apr 11 01:58, Yaakov (Cygwin/X) wrote:
>> >> On 2013-04-11 01:02, Dave Korn wrote:
>> >>>   Yep, sure.  *sigh*, I'm sure we'll suddenly find out that someone was using
>> >>> it and wants to know where it's gone.  (I suppose if that happens I could
>> >>> always consider rolling a gcc3 package with all -3 suffixed executables.)
>> >> 3.4 is EOL and should have been dropped long ago; we simply don't
>> >> have the resources to support it ourselves.  Just about any software
>> >> that people are building today either works with recent 4.x or the
>> >> distros have a patch for it.
>> >
>> > FWIW, I agree.
>> >
>> >
>> > AOL-Corinna
>>
>>   I said I could consider it, I didn't say I was necessarily going to do it :)
>>
>>   Still, you'd be surprised the number of questions I see on random websites
>> (stackoverflow, linuxquestions and similar) where someone's asking how to
>> install an old GCC to build some old software.
>
> So what?  It's definitely wrong that our "gcc" package installs an old
> gcc, rather than a recent one.  If you really want to stick to an old
> gcc, make sure it's not the default.  Call it gcc-3 or legacy-gcc, but
> let's get it out of the way of the most recent version.

Speaking of which......   4.8 is out.......

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 11/04/2013 13:22, NightStrike wrote:

> Speaking of which......   4.8 is out.......

  Point.  Anyone got any particular preference whether I go for a 4.7.3 or
4.8.0 release next?  Maybe do a 4.7.3 curr: and then a 4.8.0 test: package?

    cheers,
      DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Yaakov (Cygwin/X)]

On 2013-04-11 07:35, Dave Korn wrote:
> On 11/04/2013 13:22, NightStrike wrote:
>> Speaking of which......   4.8 is out.......

So is GNOME 3.8.0, but I tend to let others deal with the early bugs and 
catch up by .1 or even .2.

>    Point.  Anyone got any particular preference whether I go for a 4.7.3 or
> 4.8.0 release next?  Maybe do a 4.7.3 curr: and then a 4.8.0 test: package?

For the same reason, I'd go with 4.7.3 first.  But let's not wait until 
4.9 to update GCC again this time, okay? :-)


Yaakov

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 12/04/2013 00:36, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 07:35, Dave Korn wrote:
>> On 11/04/2013 13:22, NightStrike wrote:
>>> Speaking of which......   4.8 is out.......
> 
> So is GNOME 3.8.0, but I tend to let others deal with the early bugs and 
> catch up by .1 or even .2.
> 
>> Point.  Anyone got any particular preference whether I go for a 4.7.3 or 
>> 4.8.0 release next?  Maybe do a 4.7.3 curr: and then a 4.8.0 test: 
>> package?
> 
> For the same reason, I'd go with 4.7.3 first.  But let's not wait until 4.9
> to update GCC again this time, okay? :-)

  Yeh, promise!

    cheers,
      DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 11/04/2013 13:19, Corinna Vinschen wrote:

>>>> On 2013-04-11 01:02, Dave Korn wrote:
>>>>>   Yep, sure.  *sigh*, I'm sure we'll suddenly find out that someone was using
>>>>> it and wants to know where it's gone.  (I suppose if that happens I could
>>>>> always consider rolling a gcc3 package with all -3 suffixed executables.)
                              ^^^^^^^^^^^^^^
>   If you really want to stick to an old
> gcc, make sure it's not the default.  Call it gcc-3 or legacy-gcc, but
> let's get it out of the way of the most recent version.

  Yes, that's what I meant to imply by the wording.  Different name + suffixed
executables = out of the way.

  Also, I don't plan on doing it unless there's significant demand.

    cheers,
      DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Thomas Wolff]

Am 11.04.2013 14:34, schrieb Dave Korn:
> On 11/04/2013 13:19, Corinna Vinschen wrote:
>
>>>>> On 2013-04-11 01:02, Dave Korn wrote:
>>>>>>    Yep, sure.  *sigh*, I'm sure we'll suddenly find out that someone was using
>>>>>> it and wants to know where it's gone.  (I suppose if that happens I could
>>>>>> always consider rolling a gcc3 package with all -3 suffixed executables.)
>                                ^^^^^^^^^^^^^^
>>    If you really want to stick to an old
>> gcc, make sure it's not the default.  Call it gcc-3 or legacy-gcc, but
>> let's get it out of the way of the most recent version.
>    Yes, that's what I meant to imply by the wording.  Different name + suffixed
> executables = out of the way.
>
>    Also, I don't plan on doing it unless there's significant demand.
I would appreciate to keep it as gcc-3. The reason is quite peculiar; 
gcc-4 changed the order of variables in the stack frame of a function 
call, which led to one very specific interworking malfunction (between 
mintty and mined) which in turn unveiled a very subtle bug. This is 
material for very interesting debugging exercises for students... Not 
sure whether it's significant but the changed variable order might in 
fact affect other software as well.
------
Thomas

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 11/04/2013 21:42, Thomas Wolff wrote:
> Am 11.04.2013 14:34, schrieb Dave Korn:

>> Also, I don't plan on doing it unless there's significant demand.
> I would appreciate to keep it as gcc-3.

  Fancy being the maintainer for it then? ;-)

> The reason is quite peculiar; gcc-4
> changed the order of variables in the stack frame of a function call, which
> led to one very specific interworking malfunction (between mintty and
> mined) which in turn unveiled a very subtle bug. This is material for very
> interesting debugging exercises for students... Not sure whether it's
> significant but the changed variable order might in fact affect other
> software as well. ------ Thomas

  Only seriously buggy software.  Anything in a C program that attempts to
make inferences about the layout of the stack frame is invoking undefined
behaviour.

    cheers,
      DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 01:02, Dave Korn wrote:
>> Yes, I've looked at most of your patches already, I'm not saying there's
>> any complication in adding them, it's just that I didn't want to wait
>> another howevermany days before getting 4.7.2-2 out there.  I'll put them
>> all into the next release, which I'll get on with pronto.
> 
> Your boehm-gc patch can replace my java-libgc-win32.patch, provided it 
> works properly.

  It appears to, libjava testsuite results are as good as they've ever been,
although I don't know whether or not the testsuite checks the invocation API.
 It's certainly the more complete approach to take than just not supporting
the register/unregister methods, as confirmed by the fact that upstream
boehm-gc has implemented it for Cygwin.

> libitm needs some more work before enabling, at least on x86_64 due to weak
> symbol and sysv_abi assumptions (I have managed to get statically-linked
> executables to work, but not DLL-linked ones); on i686 it *might* actually
> work with just my patch (the one in 4.8 branch is better), but in the
> interest of time this should probably wait for a future release.

  I'll try it and see how the test results look.

> Also in the 4.8 branch is a patch to unversion the LTO plugin; it applies
> to 4.7 as well.

  I'll take a look for that.  Does it really matter?  I don't suppose we need
support swapping LTO plugins between different versions of the compiler, it's
totally a for-internal-use-only thing.

> Something else you missed: cygport supports a new, unversioned file format,
> and creates setup.hint files, including dependency detection.  I suggest
> using git master right now.

  Wouldn't that mean that the -src package I ship won't rebuild with the
version from the standard distribution?

>> I'll need to make sure not to lose the cc.exe -> gcc.exe symlink, and it 
>> might be useful for backward-compatibility to provide a bunch of -4 
>> suffixed links to the other executables for people who've written
>> CC=gcc-4 in their Makefiles, but that can be done with just ln rather
>> than using alternatives.
> 
> That was never right, CC isn't supposed to be (ab)used like that.  I don't
> mind not supporting that going forward.

  Well it's not exactly any trouble so I may as well do it.  If you're not
using autotools, CC is yours to do what you like with isn't it?

>> Without the .la files, libjava doesn't build.   And in general I don't
>> want to second-guess the compiler: since the upstream makefiles think
>> it's important to install them, so do I.
> 
> How could removing the .la files during postinstall affect building libjava
> beforehand?

  Heh, of course not, I'm not suggesting time travel!  I should have said
*re*build: without the .la files installed on the user's system, the -src
package fails to rebuild.  I imagine (but didn't test) that applies to
building plain upstream SVN/tarball as well.

> As for the makefiles installing the .la files, upstream isn't "choosing" to
> do so, that's just how libtool works.  Some Linux distros, including 
> Fedora, have been removing them from all binary packages (except when they
> are needed by lt_dlopen() and friends), and for very good reason.

  What's the very good reason?

>> execstack: Trampolines need an executable stack.  DEP on recent Windows
>> OSs marks the stack non-executable; this option allows the stack to be
>> set executable during the runtime startup, without having to disable DEP 
>> for the entire process.  Think I may have inherited it from Danny Smith.
>>  Mingw has it upstream, I'll get it committed there for Cygwin too.
> 
> Should this be used on x86_64 as well?  The libgcc/config.host hunk of your
> patch only mentions ix86.

  I don't know for sure, not being familiar with 64-bit world yet, but would
imagine so.

>> shared-libgcc: Makes linking against shared libgcc the default for all 
>> executables; previously it was only on by default for DLLs.  Vital for 
>> importing TLS variables from DLLs, upstream since 4.8.0.
> 
> Here we go again...

  Huh?

    cheers,
      DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Yaakov (Cygwin/X)]

On 2013-04-11 07:32, Dave Korn wrote:
> On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote:
>> Also in the 4.8 branch is a patch to unversion the LTO plugin; it applies
>> to 4.7 as well.
>
>    I'll take a look for that.  Does it really matter?  I don't suppose we need
> support swapping LTO plugins between different versions of the compiler, it's
> totally a for-internal-use-only thing.

Does it really, *really* matter?  Perhaps not, but IMO it's the proper 
thing to do for all arches, since the LTO plugin is just that, a plugin. 
  (If Apple were to still use GCC, it *would* matter, as there are 
fundamental differences between Mach-O dylibs and bundles.)

>> Something else you missed: cygport supports a new, unversioned file format,
>> and creates setup.hint files, including dependency detection.  I suggest
>> using git master right now.
>
>    Wouldn't that mean that the -src package I ship won't rebuild with the
> version from the standard distribution?

I usually recommend using cygport git master, and a number of 
maintainers track it.

>> That was never right, CC isn't supposed to be (ab)used like that.  I don't
>> mind not supporting that going forward.
>
>    Well it's not exactly any trouble so I may as well do it.  If you're not
> using autotools, CC is yours to do what you like with isn't it?

No, it's not.  In the cygport manual, [Definitions] should be treated as 
readonly, and [Variables] can be altered.

>> How could removing the .la files during postinstall affect building libjava
>> beforehand?
>
>    Heh, of course not, I'm not suggesting time travel!  I should have said
> *re*build: without the .la files installed on the user's system, the -src
> package fails to rebuild.  I imagine (but didn't test) that applies to
> building plain upstream SVN/tarball as well.

You still haven't explained exactly what the problem is.  You don't need 
libgcj on the system in order to build a native gcc with java.  Why 
would the presence or lack of libgcj*.la make a difference?

>> As for the makefiles installing the .la files, upstream isn't "choosing" to
>> do so, that's just how libtool works.  Some Linux distros, including
>> Fedora, have been removing them from all binary packages (except when they
>> are needed by lt_dlopen() and friends), and for very good reason.
>
>    What's the very good reason?

Because they cause more trouble than they're worth, e.g. necessitating 
hacks such as fix-libtool-scripts-for-latest-gcc-runtimes.sh.  This is a 
good summary of some of the issues:

https://lists.fedoraproject.org/pipermail/mingw/2012-January/004421.html

>>> shared-libgcc: Makes linking against shared libgcc the default for all
>>> executables; previously it was only on by default for DLLs.  Vital for
>>> importing TLS variables from DLLs, upstream since 4.8.0.
>>
>> Here we go again...
>
>    Huh?

We started with 4.3 using the static libgcc by default, then switched to 
linking everything with -lgcc_s, then with 4.5 switched to doing so by 
default only for DLLs (to minimize rebase errors iirc), and now we're 
going back to shared across-the-board.  I'm not complaining, and it 
seems like the right thing to do, but it does evoke a sense of deja vu.


Yaakov

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 12/04/2013 00:28, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 07:32, Dave Korn wrote:
>> On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote:
>>> Also in the 4.8 branch is a patch to unversion the LTO plugin; it 
>>> applies to 4.7 as well.
>> 
>> I'll take a look for that.  Does it really matter?  I don't suppose we
>> need support swapping LTO plugins between different versions of the 
>> compiler, it's totally a for-internal-use-only thing.
> 
> Does it really, *really* matter?  Perhaps not, but IMO it's the proper 
> thing to do for all arches, since the LTO plugin is just that, a plugin. 
> (If Apple were to still use GCC, it *would* matter, as there are 
> fundamental differences between Mach-O dylibs and bundles.)

  Well, maybe I'll just wait until I get to a 4.8 release naturally and let it
happen then.  Or maybe I'll backport the patch for 4.7.3.  I'll see how I feel
at the time, since it's not /critical/ and I'd like to prioritise.

>>> Something else you missed: cygport supports a new, unversioned file 
>>> format, and creates setup.hint files, including dependency detection.
>>> I suggest using git master right now.
>> 
>> Wouldn't that mean that the -src package I ship won't rebuild with the 
>> version from the standard distribution?
> 
> I usually recommend using cygport git master, and a number of maintainers
> track it.

  I want to ship packages that the general public can rebuild using the
standard distro really.  Do you have any idea of a schedule for releasing
these features?  (Also, what is the "unversioned file format"?)

>>> That was never right, CC isn't supposed to be (ab)used like that.  I 
>>> don't mind not supporting that going forward.
>> 
>> Well it's not exactly any trouble so I may as well do it.  If you're not 
>> using autotools, CC is yours to do what you like with isn't it?
> 
> No, it's not.  In the cygport manual, [Definitions] should be treated as 
> readonly, and [Variables] can be altered.

  Huh?  Cygport doesn't own CC any more than autotools if it's not being used.
 CC is a user variable.  It belongs to make, and the make info page in the
section on "Makefile Conventions" says that the user can substitute
alternatives.  Maintainers aren't the only people who use the compiler!

>>> How could removing the .la files during postinstall affect building 
>>> libjava beforehand?
>> 
>> Heh, of course not, I'm not suggesting time travel!  I should have said 
>> *re*build: without the .la files installed on the user's system, the -src
>>  package fails to rebuild.  I imagine (but didn't test) that applies to 
>> building plain upstream SVN/tarball as well.
> 
> You still haven't explained exactly what the problem is.  You don't need 
> libgcj on the system in order to build a native gcc with java.  Why would
> the presence or lack of libgcj*.la make a difference?

  Ah, that's where our misunderstanding is.  It's the presence of libstdc++.la
that is required for libjava to build, not libgcj.la.  That's because of a
failure during linking (the awt peer IIRC) when libtool can't locate libstdc
to link against.  That in turn happens because it uses gcc.exe to link, not
g++.exe, and that in turn happens because libtool is invoked with the CC tag,
not CXX, and that in turn happens because the module is composed entirely of
.c files and does not have any .cc files to trigger libtool's language
detection to know that C++ is required.

>>> As for the makefiles installing the .la files, upstream isn't 
>>> "choosing" to do so, that's just how libtool works.  Some Linux
>>> distros, including Fedora, have been removing them from all binary
>>> packages (except when they are needed by lt_dlopen() and friends), and
>>> for very good reason.
>> 
>> What's the very good reason?
> 
> Because they cause more trouble than they're worth, e.g. necessitating 
> hacks such as fix-libtool-scripts-for-latest-gcc-runtimes.sh.  This is a 
> good summary of some of the issues:
> 
> https://lists.fedoraproject.org/pipermail/mingw/2012-January/004421.html

  Hmm.  I need to digest that some more.  I'm not entirely certain that it
applies to the compiler runtime libs, because people often do use static
linking against them when they want to make standalone executables.

>>>> shared-libgcc: Makes linking against shared libgcc the default for
>>>> all executables; previously it was only on by default for DLLs.
>>>> Vital for importing TLS variables from DLLs, upstream since 4.8.0.
>>> 
>>> Here we go again...
>> 
>> Huh?
> 
> We started with 4.3 using the static libgcc by default, then switched to 
> linking everything with -lgcc_s, then with 4.5 switched to doing so by 
> default only for DLLs (to minimize rebase errors iirc), and now we're going
> back to shared across-the-board.  I'm not complaining, and it seems like
> the right thing to do, but it does evoke a sense of deja vu.

  Ah, I didn't remember that we'd taken a step back at one point during the
process, I thought it had been a linear progression but that does ring a bell.
 Well, I'm sure now that it was the wrong way to try and solve the rebase
problems, it's seriously incorrect to have two separate copies of the TLS
variable control array or the EH table registration roots in a running program.

    cheers,
      DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Yaakov (Cygwin/X)]

On 2013-04-11 23:24, Dave Korn wrote:
>> I usually recommend using cygport git master, and a number of maintainers
>> track it.
>
>    I want to ship packages that the general public can rebuild using the
> standard distro really.  Do you have any idea of a schedule for releasing
> these features?

Most of the discussed features are already in the latest release.  Right 
now, the major difference between the release and git master is full 
support for x86_64-pc-cygwin, but there are a number of other bugfixes 
and enhancements.  I hope to cut a release from master as early as next 
week.

> (Also, what is the "unversioned file format"?)

Where the file is named foo.cygport and NAME/VERSION/RELEASE are defined 
inside of the cygport(5) instead of deriving these from the filename as 
before.  My gcc.cygport is an example of this, as well as the use of 
setup.hint generation.

>> No, it's not.  In the cygport manual, [Definitions] should be treated as
>> readonly, and [Variables] can be altered.
>
>    Huh?  Cygport doesn't own CC any more than autotools if it's not being used.
>   CC is a user variable.  It belongs to make, and the make info page in the
> section on "Makefile Conventions" says that the user can substitute
> alternatives.  Maintainers aren't the only people who use the compiler!

*Within the scope of cygport*, cygport(1) is the "user" and it controls 
CC based on a number of factors.  CC can then be used within the 
cygport(5), e.g. with a handwritten makefile:

src_compile() {
	lndirs
	cd ${B}
	cygmake CC=${CC} CFLAGS="${CFLAGS}" AR=${AR} RANLIB=${RANLIB}
}

But like most cygport APIs, CC (and others marked as [Definitions] in 
the manual) should be treated as opaque constants; it might end up as 
gcc if building natively, or one of {i686,x86_64}-pc-cygwin-gcc if 
cross-compiling (cygport supports doing so from both Cygwin and Linux), 
${CROSS_HOST}-gcc if cross.cygclass is in use, or even clang or 
$host-clang with clang.cygclass.  Saying CC=gcc-4 obviously doesn't work 
in all those scenarios.

>> You still haven't explained exactly what the problem is.  You don't need
>> libgcj on the system in order to build a native gcc with java.  Why would
>> the presence or lack of libgcj*.la make a difference?
>
>    Ah, that's where our misunderstanding is.  It's the presence of libstdc++.la
> that is required for libjava to build, not libgcj.la.  That's because of a
> failure during linking (the awt peer IIRC) when libtool can't locate libstdc
> to link against.  That in turn happens because it uses gcc.exe to link, not
> g++.exe, and that in turn happens because libtool is invoked with the CC tag,
> not CXX, and that in turn happens because the module is composed entirely of
> .c files and does not have any .cc files to trigger libtool's language
> detection to know that C++ is required.

Oh, now I get it.  What *really* happened is that last time you tried 
this, you still had GNOME .la files on your system, some of which 
contained references to libstdc++.la because of the then-embedded copy 
of harfbuzz in the Pango libraries.  So when you installed an .la-less 
gcc then rebuilt gcc, the link failed because of the remaining 
libstdc++.la references in libgtkpeer's many (sub)deps; the same would 
have happened building *any* GTK+/GNOME package with libtool.

This would have worked even then if you had run the 
fix-libtool-scripts-for-latest-gcc-runtimes.sh script with my 
modifications thereto (Ports gcc commit 00c6f36) immediately after 
installing the .la-less gcc.  In any case, the current versions of the 
GNOME libraries do not include .la files, so you won't have this problem 
with rebuilding gcc.  (You should still run the modified script in any 
case.)

>> Because they cause more trouble than they're worth, e.g. necessitating
>> hacks such as fix-libtool-scripts-for-latest-gcc-runtimes.sh.  This is a
>> good summary of some of the issues:
>>
>> https://lists.fedoraproject.org/pipermail/mingw/2012-January/004421.html
>
>    Hmm.  I need to digest that some more.  I'm not entirely certain that it
> applies to the compiler runtime libs, because people often do use static
> linking against them when they want to make standalone executables.

On the contrary, the compiler knows best how to links its own libs 
without libtool's help; in fact, sometimes libtool tries to be *too* 
smart and ends up just getting in the way, hence the need for patches 
such as this:

http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/libtool;a=blob;f=2.4-pass-ldflags.patch;h=cd08a54;hb=HEAD

Don't get me wrong, libtool is still the best option for building 
libraries portably, but it does not need .la files on the system to do 
so with shared libraries.  Now that we've figured out what the problem 
really was, and that it doesn't exist anymore, could we drop them from 
the next release?


Yaakov

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 12/04/2013 11:44, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 23:24, Dave Korn wrote:

> Most of the discussed features are already in the latest release.  Right 
> now, the major difference between the release and git master is full 
> support for x86_64-pc-cygwin, but there are a number of other bugfixes and
> enhancements.  I hope to cut a release from master as early as next week.
> 
>> (Also, what is the "unversioned file format"?)
> 
> Where the file is named foo.cygport and NAME/VERSION/RELEASE are defined 
> inside of the cygport(5) instead of deriving these from the filename as 
> before.  My gcc.cygport is an example of this, as well as the use of 
> setup.hint generation.

  Great, then I'll take full advantage of the new stuff.

>> Huh?  Cygport doesn't own CC any more than autotools if it's not being
>> used. CC is a user variable.  It belongs to make, and the make info page 
>> in the section on "Makefile Conventions" says that the user can
>> substitute alternatives.  Maintainers aren't the only people who use the
>> compiler!
> 
> *Within the scope of cygport*, cygport(1) is the "user" and it controls CC
> based on a number of factors.
        [ ... ]
> Saying CC=gcc-4 obviously doesn't work in all those scenarios.

  Well, yes, but we're talking here about whether I should leave a symlink
called gcc-4.exe in /usr/bin for the benefit of any end users who might have
makefiles (or other scripts) that aren't in any way related to cygport at all,
so none of that is relevant.

>>> You still haven't explained exactly what the problem is.  You don't
>>> need libgcj on the system in order to build a native gcc with java.
>>> Why would the presence or lack of libgcj*.la make a difference?
>> 
>> Ah, that's where our misunderstanding is.  It's the presence of 
>> libstdc++.la that is required for libjava to build, not libgcj.la.
        [ ... ]
> Oh, now I get it.  What *really* happened is that last time you tried this,
> you still had GNOME .la files on your system, some of which contained
> references to libstdc++.la because of the then-embedded copy of harfbuzz in
> the Pango libraries.  So when you installed an .la-less gcc then rebuilt
> gcc, the link failed because of the remaining libstdc++.la references in
> libgtkpeer's many (sub)deps; the same would have happened building *any*
> GTK+/GNOME package with libtool.
> 
> This would have worked even then if you had run the 
> fix-libtool-scripts-for-latest-gcc-runtimes.sh script with my modifications
> thereto (Ports gcc commit 00c6f36) immediately after installing the
> .la-less gcc.  In any case, the current versions of the GNOME libraries do
> not include .la files, so you won't have this problem with rebuilding gcc.
> (You should still run the modified script in any case.)

  Ah, thanks for the explanation.  That makes sense to me.

> Don't get me wrong, libtool is still the best option for building libraries
> portably, but it does not need .la files on the system to do so with shared
> libraries.  Now that we've figured out what the problem really was, and
> that it doesn't exist anymore, could we drop them from the next release?

  Absolutely, assuming nothing goes wrong when I test it.

  I should still package the updated version of
fix-libtool-scripts-for-latest-gcc-runtimes.sh and invoke it postinstall for
the benefit of any other .la files that are still on the system, right?

    cheers,
      DaveK

Re: GCC-4.7.2-2: Go/No-go?

[Yaakov (Cygwin/X)]

On 2013-04-12 12:34, Dave Korn wrote:
>    I should still package the updated version of
> fix-libtool-scripts-for-latest-gcc-runtimes.sh and invoke it postinstall for
> the benefit of any other .la files that are still on the system, right?

Yes, absolutely.


Yaakov

Re: GCC-4.7.2-2: Go/No-go?

[Yaakov (Cygwin/X)]

On 2013-04-11 07:32, Dave Korn wrote:
> On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote:
>> Your boehm-gc patch can replace my java-libgc-win32.patch, provided it
>> works properly.
>
>    It appears to, libjava testsuite results are as good as they've ever been,
> although I don't know whether or not the testsuite checks the invocation API.
>   It's certainly the more complete approach to take than just not supporting
> the register/unregister methods, as confirmed by the fact that upstream
> boehm-gc has implemented it for Cygwin.

There is a mistake in that patch.  The DEBUG_CYGWIN_THREADS conditionals 
need to be "if", not "ifdef", as elsewhere in the same source file.


Yaakov

Re: GCC-4.7.2-2: Go/No-go?

[Dave Korn]

On 17/04/2013 19:59, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 07:32, Dave Korn wrote:
>> On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote:
>>> Your boehm-gc patch can replace my java-libgc-win32.patch, provided it
>>> works properly.
>>
>>    It appears to, libjava testsuite results are as good as they've
>> ever been,
>> although I don't know whether or not the testsuite checks the
>> invocation API.
>>   It's certainly the more complete approach to take than just not
>> supporting
>> the register/unregister methods, as confirmed by the fact that upstream
>> boehm-gc has implemented it for Cygwin.
> 
> There is a mistake in that patch.  The DEBUG_CYGWIN_THREADS conditionals
> need to be "if", not "ifdef", as elsewhere in the same source file.

  Oops, that was a cut'n'paste error when I copied the skeleton of those
functions from pthread_support.c, where #ifdef DEBUG_THREADS is the form to
use.  Thanks for spotting it; fixed in my repo ready for next release.

    cheers,
      DaveK

Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]

[Charles Wilson]

On 4/11/2013 2:58 AM, Yaakov (Cygwin/X) wrote:
> Something else you missed: cygport supports a new, unversioned file
> format, and creates setup.hint files, including dependency detection.  I
> suggest using git master right now.

I know that cygwin-specific READMEs are now no longer required or 
expected in cygwin packages. However, I like to keep mine around to 
document things like packaging history, cygwin-specific user notes, 
build dependencies, and the like.

I'll admit, tho, that avoiding the need to maintain setup.hints outside 
of the cygport(5) is nice, at least for simple package sets (that have 
only one "binary" tarball, plus the -src and the debuginfo).

Three questions:

#1) Is it possible to also record cygwin-specific README content within 
the cygport(5)? [1] If so, can you do more than one? (I'm thinking here 
of inetutils, which has a separate cygwin-specific README for the 
-server (sub)package and for the -client (sub)package).

#2) Is it possible to use the auto-setup.hint-generator functionality 
for multi-part package sets (e.g. which contain multiple separate 
tarballs, in addition to -src and -debuginfo)? If so, how?

#3) As I've been gone for a while, I might've missed recent changes: do 
setup.exe and/or cygport support build dependencies directly in any way, 
rather than the ad-hoc put-it-in-a-cygwin-README "technique" I've been 
using 'til now?

[1] And I don't mean just putting a giant block of #-comment lines in 
the cygport(5). I mean ensuring that something gets intalled into 
/usr/share/doc/Cygwin/ with the appropriate name and all.

--
Chuck

Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]

[Achim Gratz]

While the mirror script pulls down the shiny new gcc from Dave…

Charles Wilson writes:
> #1) Is it possible to also record cygwin-specific README content
> within the cygport(5)? [1] If so, can you do more than one? (I'm
> thinking here of inetutils, which has a separate cygwin-specific
> README for the -server (sub)package and for the -client (sub)package).

Here scripts (cat > file <<EOF) would work, I've been using that to drop
some few-line-long script in-place into the build once.  I don't think
it would necessarily work well for the README files, but I guess it's
possible to append them to SRC_URI (you'd have to move them to the
CYGWIN_PATCHES directory, though).  If it's just the fact that editing a
patch file is ugly, then you could do something along the lines of "diff
-u /dev/null package.README > package.README.patch" and then add
package.README.patch to the PATCH_URI.  But maybe Yaakov could consider
something like README_URI instead (I think I could provide a patch to
that effect).

> #2) Is it possible to use the auto-setup.hint-generator functionality
> for multi-part package sets (e.g. which contain multiple separate
> tarballs, in addition to -src and -debuginfo)? If so, how?

Yes, look at the recent packages for gmp/mpfr etc.

> #3) As I've been gone for a while, I might've missed recent changes:
> do setup.exe and/or cygport support build dependencies directly in any
> way, rather than the ad-hoc put-it-in-a-cygwin-README "technique" I've
> been using 'til now?

I try to add both the requisite require lines to the *-devel package and
a depend line in the cygport file.



HTH,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]

[Yaakov (Cygwin/X)]

On 2013-04-11 07:37, Charles Wilson wrote:
> #1) Is it possible to also record cygwin-specific README content within
> the cygport(5)? [1] If so, can you do more than one? (I'm thinking here
> of inetutils, which has a separate cygwin-specific README for the
> -server (sub)package and for the -client (sub)package).

No, cygport(1) doesn't generate README content.

> #2) Is it possible to use the auto-setup.hint-generator functionality
> for multi-part package sets (e.g. which contain multiple separate
> tarballs, in addition to -src and -debuginfo)? If so, how?

Yes; it just works, and also handles inter-subpackage dependencies (e.g. 
apps in foo will dep libfooX, and implibs in libfoo-devel will dep the 
corresponding DLL in libfooX).  Just define CATEGORY/SUMMARY/DESCRIPTION 
(there are also subpackage-specific variants of these) and omit the hint 
files from $C; at the end of the package stage, cygport will show you 
the dependencies it computes for each package so you can check them.  If 
there are undetectable deps (e.g. commands called by a script or fork(), 
or runtime data, etc.), then those can be added in [$subpackage]_REQUIRES.

> #3) As I've been gone for a while, I might've missed recent changes: do
> setup.exe and/or cygport support build dependencies directly in any way,
> rather than the ad-hoc put-it-in-a-cygwin-README "technique" I've been
> using 'til now?

See DEPEND in the cygport manual.  (Yes, this is confusing now that 
REQUIRES exists for additional *runtime* dependencies.  I'm thinking of 
renaming this to BUILDREQUIRES or the like, but for API compatibility 
DEPEND would still work.)  These are checked at the beginning of the 
build step, and a warning issued if any are missing.


Yaakov

Re: Recent cygport and cygwin-specific READMEs

[Charles Wilson]

On 4/11/2013 6:37 PM, Yaakov (Cygwin/X) wrote:
> No, cygport(1) doesn't generate README content.

Too bad.  Well, maintaining the READMEs in my local git repo 
side-by-side with the cygport(5) is not that big a deal -- especially 
with the other cygport(1) improvements, incl #3 below.

>> #2) Is it possible to use the auto-setup.hint-generator functionality
>> for multi-part package sets (e.g. which contain multiple separate
>> tarballs, in addition to -src and -debuginfo)? If so, how?
>
> Yes; it just works

Fabulous.

>> #3) As I've been gone for a while, I might've missed recent changes: do
>> setup.exe and/or cygport support build dependencies directly in any way,
>> rather than the ad-hoc put-it-in-a-cygwin-README "technique" I've been
>> using 'til now?
>
> See DEPEND in the cygport manual.  (Yes, this is confusing now that
> REQUIRES exists for additional *runtime* dependencies.  I'm thinking of
> renaming this to BUILDREQUIRES or the like, but for API compatibility
> DEPEND would still work.)  These are checked at the beginning of the
> build step, and a warning issued if any are missing.

Great -- which actually means I can remove that bit from the 
cygwin-specific READMEs.  That's the most annoying part of keeping the 
READMEs up-to-date anyway.

--
Chuck

Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]

[Andy Koppe]

On 11 April 2013 23:37, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 07:37, Charles Wilson wrote:
>> #2) Is it possible to use the auto-setup.hint-generator functionality
>> for multi-part package sets (e.g. which contain multiple separate
>> tarballs, in addition to -src and -debuginfo)? If so, how?
>
>
> Yes; it just works, and also handles inter-subpackage dependencies (e.g.
> apps in foo will dep libfooX, and implibs in libfoo-devel will dep the
> corresponding DLL in libfooX).  Just define CATEGORY/SUMMARY/DESCRIPTION
> (there are also subpackage-specific variants of these) and omit the hint
> files from $C; at the end of the package stage, cygport will show you the
> dependencies it computes for each package so you can check them.

I'm struggling to get setup.hint generation to work. Is it supported
with cygport 0.11.3 as currently in the distros? Below is the
mintty.cygport I've got. Do I need to do anything else to trigger it?

Cygport prints ">>> mintty requires:" at the end, which is correct as
it doesn't require anything beyond the Cygwin DLL, but there's no
setup.hint.

I've also tried installing cygport from git master but got this after
running ./autogen.sh && make:

make: *** No rule to make target `data/gnuconfig/config.guess', needed
by `all-am'.  Stop.

Andy


mintty.cygport:
NAME=mintty
VERSION=1.2-beta1
RELEASE=1
CATEGORY="Base Shells"
DEPEND="make gcc-core w32api"
HOMEPAGE="http://mintty.googlecode.com"
SRC_URI="http://mintty.googlecode.com/files/mintty-${PV}-src.tar.bz2"
SUMMARY="Terminal emulator with native Windows look and feel"
DESCRIPTION="\
Mintty is a terminal emulator for Cygwin. It is based on code
from PuTTY 0.60 by Simon Tatham and team.

Features include:
* Xterm-compatible terminal emulation.
* Full Unicode support.
* Native Windows user interface that tries to keep things simple.
* Graphical options dialog. Options stored in a text file.
* Drag & drop and copy & paste of text, files and folders.
* Extensive mouse support.
* Window transparency."

_CYGPORT_RESTRICT_postinst_doc_=1

src_compile() {
  lndirs
  cd ${B}
  cygmake
}

src_install() {
  cd ${B}
  dobin mintty.exe
  insinto /usr/share/man/man1
  doins docs/mintty.1
  dodoc COPYING
  dodoc LICENSE.Oxygen
  dodoc LICENSE.PuTTY
}

Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]

[Achim Gratz]

Andy Koppe writes:
> I'm struggling to get setup.hint generation to work. Is it supported
> with cygport 0.11.3 as currently in the distros? Below is the
> mintty.cygport I've got. Do I need to do anything else to trigger it?

Try the cygport from Git master, I believe it should fix that.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]

[Corinna Vinschen]

On Apr 13 06:55, Andy Koppe wrote:
> On 11 April 2013 23:37, Yaakov (Cygwin/X) wrote:
> > On 2013-04-11 07:37, Charles Wilson wrote:
> >> #2) Is it possible to use the auto-setup.hint-generator functionality
> >> for multi-part package sets (e.g. which contain multiple separate
> >> tarballs, in addition to -src and -debuginfo)? If so, how?
> >
> >
> > Yes; it just works, and also handles inter-subpackage dependencies (e.g.
> > apps in foo will dep libfooX, and implibs in libfoo-devel will dep the
> > corresponding DLL in libfooX).  Just define CATEGORY/SUMMARY/DESCRIPTION
> > (there are also subpackage-specific variants of these) and omit the hint
> > files from $C; at the end of the package stage, cygport will show you the
> > dependencies it computes for each package so you can check them.
> 
> I'm struggling to get setup.hint generation to work. Is it supported
> with cygport 0.11.3 as currently in the distros? Below is the
> mintty.cygport I've got. Do I need to do anything else to trigger it?
> 
> Cygport prints ">>> mintty requires:" at the end, which is correct as
> it doesn't require anything beyond the Cygwin DLL, but there's no
> setup.hint.

Sure?  Did you look into the "dist" subdir in your builddir after
the install stage?  It should contain a complete mintty dir for
upload.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]

[Andy Koppe]

On 13 April 2013 10:03, Corinna Vinschen wrote:
> On Apr 13 06:55, Andy Koppe wrote:
>> On 11 April 2013 23:37, Yaakov (Cygwin/X) wrote:
>> > On 2013-04-11 07:37, Charles Wilson wrote:
>> >> #2) Is it possible to use the auto-setup.hint-generator functionality
>> >> for multi-part package sets (e.g. which contain multiple separate
>> >> tarballs, in addition to -src and -debuginfo)? If so, how?
>> >
>> >
>> > Yes; it just works, and also handles inter-subpackage dependencies (e.g.
>> > apps in foo will dep libfooX, and implibs in libfoo-devel will dep the
>> > corresponding DLL in libfooX).  Just define CATEGORY/SUMMARY/DESCRIPTION
>> > (there are also subpackage-specific variants of these) and omit the hint
>> > files from $C; at the end of the package stage, cygport will show you the
>> > dependencies it computes for each package so you can check them.
>>
>> I'm struggling to get setup.hint generation to work. Is it supported
>> with cygport 0.11.3 as currently in the distros? Below is the
>> mintty.cygport I've got. Do I need to do anything else to trigger it?
>>
>> Cygport prints ">>> mintty requires:" at the end, which is correct as
>> it doesn't require anything beyond the Cygwin DLL, but there's no
>> setup.hint.
>
> Sure?  Did you look into the "dist" subdir in your builddir after
> the install stage?  It should contain a complete mintty dir for
> upload.

You're right, there is, inside the working directory created by
cygport, and it looks correct. I'd expected the setup.hint to appear
next to the .cygport and the packaged .tar.bz2 files.

Thanks,
Andy

Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]

[Corinna Vinschen]

On Apr 13 12:39, Andy Koppe wrote:
> On 13 April 2013 10:03, Corinna Vinschen wrote:
> > On Apr 13 06:55, Andy Koppe wrote:
> >> I'm struggling to get setup.hint generation to work. Is it supported
> >> with cygport 0.11.3 as currently in the distros? Below is the
> >> mintty.cygport I've got. Do I need to do anything else to trigger it?
> >>
> >> Cygport prints ">>> mintty requires:" at the end, which is correct as
> >> it doesn't require anything beyond the Cygwin DLL, but there's no
> >> setup.hint.
> >
> > Sure?  Did you look into the "dist" subdir in your builddir after
> > the install stage?  It should contain a complete mintty dir for
> > upload.
> 
> You're right, there is, inside the working directory created by
> cygport, and it looks correct. I'd expected the setup.hint to appear
> next to the .cygport and the packaged .tar.bz2 files.

IIU Yaakov C, the dist dir is the way to go in future.  The toplevel
files is the old style, supposed to go away at one point.  I like the
dist dir approach a lot.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]

[Dave Korn]

On 13/04/2013 15:49, Corinna Vinschen wrote:
> On Apr 13 12:39, Andy Koppe wrote:
>> On 13 April 2013 10:03, Corinna Vinschen wrote:
>>> On Apr 13 06:55, Andy Koppe wrote:
>>>> I'm struggling to get setup.hint generation to work. Is it supported
>>>> with cygport 0.11.3 as currently in the distros? Below is the
>>>> mintty.cygport I've got. Do I need to do anything else to trigger it?
>>>>
>>>> Cygport prints ">>> mintty requires:" at the end, which is correct as
>>>> it doesn't require anything beyond the Cygwin DLL, but there's no
>>>> setup.hint.
>>> Sure?  Did you look into the "dist" subdir in your builddir after
>>> the install stage?  It should contain a complete mintty dir for
>>> upload.
>> You're right, there is, inside the working directory created by
>> cygport, and it looks correct. I'd expected the setup.hint to appear
>> next to the .cygport and the packaged .tar.bz2 files.
> 
> IIU Yaakov C, the dist dir is the way to go in future.  The toplevel
> files is the old style, supposed to go away at one point.  I like the
> dist dir approach a lot.

  Glad to hear that.  I also much prefer the dist dir to plonking all the
files in the toplevel with no directory structure.  It's much simpler for
uploading.

    cheers,
      DaveK

Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]

[Yaakov (Cygwin/X)]

On 2013-04-13 00:55, Andy Koppe wrote:
> Cygport prints ">>> mintty requires:" at the end, which is correct as
> it doesn't require anything beyond the Cygwin DLL, but there's no
> setup.hint.

As Corinna already pointed out, this is a sign that the setup.hint 
generation succeeded, and in this case the requires: line is blank (and 
rightfully so, since mintty uses only cygwin1.dll and Win32 APIs).  If 
it had failed, there would have been a warning about a missing .hint 
file instead.

> I've also tried installing cygport from git master but got this after
> running ./autogen.sh && make:
>
> make: *** No rule to make target `data/gnuconfig/config.guess', needed
> by `all-am'.  Stop.

This is one quirk of git that I've never understood: git clone does not 
expand submodules by default without the --recursive flag.  Run "git 
submodule update --init" to get these after a clone.

BTW:

> _CYGPORT_RESTRICT_postinst_doc_=1

Variables beginning with an underscore are for internal use only.  This 
should be RESTRICT=postinstall-doc.  But what problem did you encounter 
to necessitate this?

>    insinto /usr/share/man/man1
>    doins docs/mintty.1

doman docs/mintty.1

>    dodoc COPYING
>    dodoc LICENSE.Oxygen
>    dodoc LICENSE.PuTTY

FYI, dodoc takes multiple arguments.


Yaakov

Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]

[Andy Koppe]

On 14 April 2013 04:45, Yaakov (Cygwin/X) wrote:
> On 2013-04-13 00:55, Andy Koppe wrote:
>>
>> Cygport prints ">>> mintty requires:" at the end, which is correct as
>> it doesn't require anything beyond the Cygwin DLL, but there's no
>> setup.hint.
>
>
> As Corinna already pointed out, this is a sign that the setup.hint
> generation succeeded, and in this case the requires: line is blank (and
> rightfully so, since mintty uses only cygwin1.dll and Win32 APIs).  If it
> had failed, there would have been a warning about a missing .hint file
> instead.
>
>
>> I've also tried installing cygport from git master but got this after
>> running ./autogen.sh && make:
>>
>> make: *** No rule to make target `data/gnuconfig/config.guess', needed
>> by `all-am'.  Stop.
>
>
> This is one quirk of git that I've never understood: git clone does not
> expand submodules by default without the --recursive flag.  Run "git
> submodule update --init" to get these after a clone.

Yep, that did it.

> BTW:
>
>> _CYGPORT_RESTRICT_postinst_doc_=1
>
>
> Variables beginning with an underscore are for internal use only.  This
> should be RESTRICT=postinstall-doc.  But what problem did you encounter to
> necessitate this?

Took me a while to remember, but it's there to stop the LICENSE file
from being installed, because that's the same as
/usr/share/doc/common-licenses/GPL-3.0. RESTRICT=postinstall-doc
didn't do this, but RESTRICT=postinst_doc does.

Thanks,
Andy

Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]

[Charles Wilson]

On 4/13/2013 11:45 PM, Yaakov (Cygwin/X) wrote:
> On 2013-04-13 00:55, Andy Koppe wrote:
>> I've also tried installing cygport from git master but got this after
>> running ./autogen.sh && make:
>>
>> make: *** No rule to make target `data/gnuconfig/config.guess', needed
>> by `all-am'.  Stop.
>
> This is one quirk of git that I've never understood: git clone does not
> expand submodules by default without the --recursive flag.  Run "git
> submodule update --init" to get these after a clone.

Something very odd: when I do this, I get fork errors:

$ /usr/bin/git submodule update --init
Submodule 'data/gnuconfig' () registered for path 'data/gnuconfig'
       2 [main] git-fetch 6928 fork: child -1 - forked process 9228 died 
unexpectedly, retry 0, exit code -1073741515, errno 11
error: cannot fork() for rev-list: Resource temporarily unavailable
error: Could not run 'git rev-list'
remote: Counting objects: 3403, done.
remote: Compressing objects: 100% (1576/1576), done.
  294079 [main] git-fetch 6928 fork: child -1 - forked process 10000 
died unexpectedly, retry 0, exit code -1073741515, errno 11
error: cannot fork() for index-pack: Resource temporarily unavailable
fatal: fetch-pack: unable to fork off index-pack
Unable to fetch in submodule path 'data/gnuconfig'


But, if I do this instead:

$ PATH=/usr/bin /usr/bin/git submodule update --init
Submodule 'data/gnuconfig' () registered for path 'data/gnuconfig'
remote: Counting objects: 3403, done.
remote: Compressing objects: 100% (1576/1576), done.
remote: Total 3403 (delta 1786), reused 3403 (delta 1786)
Receiving objects: 100% (3403/3403), 541.65 KiB | 720 KiB/s, done.
Resolving deltas: 100% (1786/1786), done.
 From git://git.sv.gnu.org/config
  * [new branch]      linux-overhaul-20010122 -> 
origin/linux-overhaul-20010122
  * [new branch]      master     -> origin/master
 From git://git.sv.gnu.org/config
  * [new tag]         before-miles-orphaned-changes -> 
before-miles-orphaned-changes
  * [new tag]         before-thomas-posix1996 -> before-thomas-posix1996
  * [new tag]         gnumach-release-1-1-1 -> gnumach-release-1-1-1
  * [new tag]         gnumach-release-1-1-3 -> gnumach-release-1-1-3
  * [new tag]         post-cagney-2000-02-15 -> post-cagney-2000-02-15
  * [new tag]         pre-cagney-2000-02-15 -> pre-cagney-2000-02-15
  * [new tag]         release-0-1 -> release-0-1
  * [new tag]         release-1-0 -> release-1-0
Submodule path 'data/gnuconfig': checked out 
'fd4dee4466c2b7bc330ff61430460e8bf6e26ddd'


it works.  Why would simply shortening the PATH have this effect?

--
Chuck

Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]

[Corinna Vinschen]

On Apr 24 00:52, Charles Wilson wrote:
> On 4/13/2013 11:45 PM, Yaakov (Cygwin/X) wrote:
> >On 2013-04-13 00:55, Andy Koppe wrote:
> >>I've also tried installing cygport from git master but got this after
> >>running ./autogen.sh && make:
> >>
> >>make: *** No rule to make target `data/gnuconfig/config.guess', needed
> >>by `all-am'.  Stop.
> >
> >This is one quirk of git that I've never understood: git clone does not
> >expand submodules by default without the --recursive flag.  Run "git
> >submodule update --init" to get these after a clone.
> 
> Something very odd: when I do this, I get fork errors:
> 
> $ /usr/bin/git submodule update --init
> [...]
>  294079 [main] git-fetch 6928 fork: child -1 - forked process 10000
> died unexpectedly, retry 0, exit code -1073741515, errno 11
> error: cannot fork() for index-pack: Resource temporarily unavailable
> fatal: fetch-pack: unable to fork off index-pack
> Unable to fetch in submodule path 'data/gnuconfig'
> 
> 
> But, if I do this instead:
> 
> $ PATH=/usr/bin /usr/bin/git submodule update --init
> [...]
> 
> it works.  Why would simply shortening the PATH have this effect?

Do you have a big environment?  Thre's a chance that the stack address
moves due to that.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]

[Charles Wilson]

On 4/24/2013 4:34 AM, Corinna Vinschen wrote:
> On Apr 24 00:52, Charles Wilson wrote:
>> Why would simply shortening the PATH have this effect?
>
> Do you have a big environment?  Thre's a chance that the stack address
> moves due to that.

$ printenv | wc
      65     116    2418

$ echo $PATH | wc
       1      19     472

Is that "big"?

--
Chuck

Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]

[Corinna Vinschen]

On Apr 24 09:54, Charles Wilson wrote:
> On 4/24/2013 4:34 AM, Corinna Vinschen wrote:
> >On Apr 24 00:52, Charles Wilson wrote:
> >>Why would simply shortening the PATH have this effect?
> >
> >Do you have a big environment?  Thre's a chance that the stack address
> >moves due to that.
> 
> $ printenv | wc
>      65     116    2418
> 
> $ echo $PATH | wc
>       1      19     472
> 
> Is that "big"?

No.  Sorry, I have no idea what the problem is here.  Did you rebase
again, just to be sure?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: GCC-4.7.2-2: Go/No-go?

[Yaakov (Cygwin/X)]

On 2013-04-09 11:17, Dave Korn wrote:
>    I have a release of 4.7.2-2 ready to upload.

FYI, there is still the issue with Ada code linked with -bargs -shared 
not exiting normally[1].  As this is not a regression from 4.5, and only 
affects GNAT, please don't hold up 4.7.3 over this, but it would be nice 
if you could manage to fix it eventually, or else drop the shared 
libgnat if it can't be made to work.


Yaakov

[1] http://cygwin.com/ml/cygwin/2010-08/msg00412.html (item #4)