Changing dependent library version numbers vs. test packages vs. requires: lines.

Changing dependent library version numbers vs. test packages vs. requires: lines.

[Dave Korn]

    Hi all,

  I've got a gcc-4.7.2 package almost ready to upload, but there's one issue
I'm not sure what's best to do about.

  Several of the runtime libs have changed version numbers, i.e.
libgnat4.5->libgnat4.7, libgcj11->libgcj13, libobjc2->libobjc4.

  I'd like to release a test: version of the new compiler, but I don't know
what's best to do for the requires: lines in the setup hint files.

  If I add the new library versions, those dependencies will also be pulled in
by people installing the curr: version of the compiler, but the new libraries
won't exist in curr: versions.

  If I don't, people installing the test: version will have to ensure they
manually select the new runtime libraries, which might be the least worst option.

  Is there any better way to handle this situation?

    cheers,
      DaveK

Re: Changing dependent library version numbers vs. test packages vs. requires: lines.

[marco atzeri]

On 11/23/2012 6:17 PM, Dave Korn wrote:
>
>      Hi all,
>
>    I've got a gcc-4.7.2 package almost ready to upload, but there's one issue
> I'm not sure what's best to do about.
>
>    Several of the runtime libs have changed version numbers, i.e.
> libgnat4.5->libgnat4.7, libgcj11->libgcj13, libobjc2->libobjc4.
>
>    I'd like to release a test: version of the new compiler, but I don't know
> what's best to do for the requires: lines in the setup hint files.
>
>    If I add the new library versions, those dependencies will also be pulled in
> by people installing the curr: version of the compiler, but the new libraries
> won't exist in curr: versions.
>
>    If I don't, people installing the test: version will have to ensure they
> manually select the new runtime libraries, which might be the least worst option.
>
>    Is there any better way to handle this situation?
>
>      cheers,
>        DaveK
>

I doubt until someone changes setup.
Put all the dependencies on your Announce, who want to try should be 
able to install them.

Marco

Re: Changing dependent library version numbers vs. test packages vs. requires: lines.

[Corinna Vinschen]

On Nov 24 06:54, marco atzeri wrote:
> On 11/23/2012 6:17 PM, Dave Korn wrote:
> >
> >     Hi all,
> >
> >   I've got a gcc-4.7.2 package almost ready to upload, but there's one issue
> >I'm not sure what's best to do about.
> >
> >   Several of the runtime libs have changed version numbers, i.e.
> >libgnat4.5->libgnat4.7, libgcj11->libgcj13, libobjc2->libobjc4.
> >
> >   I'd like to release a test: version of the new compiler, but I don't know
> >what's best to do for the requires: lines in the setup hint files.
> >
> >   If I add the new library versions, those dependencies will also be pulled in
> >by people installing the curr: version of the compiler, but the new libraries
> >won't exist in curr: versions.
> >
> >   If I don't, people installing the test: version will have to ensure they
> >manually select the new runtime libraries, which might be the least worst option.
> >
> >   Is there any better way to handle this situation?
> >
> >     cheers,
> >       DaveK
> >
> 
> I doubt until someone changes setup.
> Put all the dependencies on your Announce, who want to try should be
> able to install them.
> 
> Marco

ACK.


Corinna

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

Re: Changing dependent library version numbers vs. test packages vs. requires: lines.

[Chris Sutcliffe]

Hi Dave,

>   I've got a gcc-4.7.2 package almost ready to upload, but there's one issue
> I'm not sure what's best to do about.

Any progress on a gcc-4.7.x release for Cygwin?

Thanks,

Chris

--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

Re: Changing dependent library version numbers vs. test packages vs. requires: lines.

[Corinna Vinschen]

Dave?  Ping?

On Jan 14 11:50, Chris Sutcliffe wrote:
> Hi Dave,
> 
> >   I've got a gcc-4.7.2 package almost ready to upload, but there's one issue
> > I'm not sure what's best to do about.
> 
> Any progress on a gcc-4.7.x release for Cygwin?
> 
> Thanks,
> 
> Chris
> 
> --
> Chris Sutcliffe
> http://emergedesktop.org
> http://www.google.com/profiles/ir0nh34d

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

Re: Changing dependent library version numbers vs. test packages vs. requires: lines.

[Corinna Vinschen]

Dave,

On Jan 18 14:32, Corinna Vinschen wrote:
> Dave?  Ping?
> 
> On Jan 14 11:50, Chris Sutcliffe wrote:
> > Hi Dave,
> > 
> > >   I've got a gcc-4.7.2 package almost ready to upload, but there's one issue
> > > I'm not sure what's best to do about.
> > 
> > Any progress on a gcc-4.7.x release for Cygwin?
> > 
> > Thanks,
> > 
> > Chris

since you replied to us in private already I know that you're still
around somewhere.  I just don't understand why you reply once, only to
disappear again for a long time.  If you're not able to keep up
comunication or maintainance of GCC anymore, please just say so.
There's nothing inherently wrong or bad with that.  Live goes on and we
all know that.

But *please* don't leave us high and dry.

I think we're now waiting for a sign of progress on GCC for too long.
I don't think we can wait much longer.  If you're still happy to
maintain Cygwin's GCC, please provide a new package within the next two
weeks.  Otherwise, from my point of view GCC is up for grabs.


Thanks,
Corinna

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

Re: Changing dependent library version numbers vs. test packages vs. requires: lines.

[Chris Sutcliffe]

On 4 February 2013 05:16, Corinna Vinschen wrote:
> I think we're now waiting for a sign of progress on GCC for too long.
> I don't think we can wait much longer.  If you're still happy to
> maintain Cygwin's GCC, please provide a new package within the next two
> weeks.  Otherwise, from my point of view GCC is up for grabs.

I believe it's been 2 weeks, any chance someone will lead the charge
and provide a new GCC?

Thanks,

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

GCC maintainer volunteer? (was Re: Changing dependent library version numbers vs. test packages vs. requires: lines.)

[Corinna Vinschen]

On Feb 18 18:59, Chris Sutcliffe wrote:
> On 4 February 2013 05:16, Corinna Vinschen wrote:
> > I think we're now waiting for a sign of progress on GCC for too long.
> > I don't think we can wait much longer.  If you're still happy to
> > maintain Cygwin's GCC, please provide a new package within the next two
> > weeks.  Otherwise, from my point of view GCC is up for grabs.
> 
> I believe it's been 2 weeks, any chance someone will lead the charge
> and provide a new GCC?

Yeah, it's really too bad.  I had so hoped that Dave would still be with
us.

I now orphaned all gcc packages in cygwin-pkg-maint.

If anybody feels bold enough to take up gcc maintainership, please step
forward.

It would be most appreciated if you would also be willing to take over
maintainership of the 64 bit compiler, as soon as we start the official
64 bit distro (later this year).  But that's an entirely different
beast, so we could also split maintainership, especially given the
requirement to provide cross compilers 32->64 and 64->32 bit, too.


Thanks in advance,
Corinna

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

Re: GCC maintainer volunteer? (was Re: Changing dependent library version numbers vs. test packages vs. requires: lines.)

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

On 2/19/2013 15:46, Corinna Vinschen wrote:
> On Feb 18 18:59, Chris Sutcliffe wrote:
>> On 4 February 2013 05:16, Corinna Vinschen wrote:
>>> I think we're now waiting for a sign of progress on GCC for too long.
>>> I don't think we can wait much longer.  If you're still happy to
>>> maintain Cygwin's GCC, please provide a new package within the next two
>>> weeks.  Otherwise, from my point of view GCC is up for grabs.
>>
>> I believe it's been 2 weeks, any chance someone will lead the charge
>> and provide a new GCC?
> 
> Yeah, it's really too bad.  I had so hoped that Dave would still be with
> us.
> 
> I now orphaned all gcc packages in cygwin-pkg-maint.
> 
> If anybody feels bold enough to take up gcc maintainership, please step
> forward.
> 
> It would be most appreciated if you would also be willing to take over
> maintainership of the 64 bit compiler, as soon as we start the official
> 64 bit distro (later this year).  But that's an entirely different
> beast, so we could also split maintainership, especially given the
> requirement to provide cross compilers 32->64 and 64->32 bit, too.
> 

I can give Cygwin GCC a try over the weekends. Not sure if it is too
complicated.

Well, if someone else wants to take maintainership, feel free to over
take me :)



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: GCC maintainer volunteer? (was Re: Changing dependent library version numbers vs. test packages vs. requires: lines.)

[Yaakov]

On Tue, 19 Feb 2013 18:21:56 +0800, JonY wrote:
> I can give Cygwin GCC a try over the weekends. Not sure if it is too
> complicated.
> 
> Well, if someone else wants to take maintainership, feel free to over
> take me :)

Please let me know if I can help; I have a fair amount of experience
with building and packaging GCC, but no so much with the internals.


Yaakov

Re: GCC maintainer volunteer? (was Re: Changing dependent library version numbers vs. test packages vs. requires: lines.)

[JonY]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

On 2/19/2013 19:46, Yaakov (Cygwin/X) wrote:
> On Tue, 19 Feb 2013 18:21:56 +0800, JonY wrote:
>> I can give Cygwin GCC a try over the weekends. Not sure if it is too
>> complicated.
>>
>> Well, if someone else wants to take maintainership, feel free to over
>> take me :)
> 
> Please let me know if I can help; I have a fair amount of experience
> with building and packaging GCC, but no so much with the internals.
> 

Actually neither do I, just enough to make minor changes.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: GCC maintainer volunteer? (was Re: Changing dependent library version numbers vs. test packages vs. requires: lines.)

[JonY]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

On 2/19/2013 20:53, JonY wrote:
> On 2/19/2013 19:46, Yaakov (Cygwin/X) wrote:
>> On Tue, 19 Feb 2013 18:21:56 +0800, JonY wrote:
>>> I can give Cygwin GCC a try over the weekends. Not sure if it is too
>>> complicated.
>>>
>>> Well, if someone else wants to take maintainership, feel free to over
>>> take me :)
>>
>> Please let me know if I can help; I have a fair amount of experience
>> with building and packaging GCC, but no so much with the internals.
>>
> 
> Actually neither do I, just enough to make minor changes.
> 
> 

I've started looking at the patches, they definitely aren't trivial.
I'll probably be releasing it as experimental.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: GCC maintainer volunteer? (was Re: Changing dependent library version numbers vs. test packages vs. requires: lines.)

[NightStrike]

On Thu, Feb 21, 2013 at 1:53 AM, JonY <10walls@gmail.com> wrote:
> On 2/19/2013 20:53, JonY wrote:
>> On 2/19/2013 19:46, Yaakov (Cygwin/X) wrote:
>>> On Tue, 19 Feb 2013 18:21:56 +0800, JonY wrote:
>>>> I can give Cygwin GCC a try over the weekends. Not sure if it is too
>>>> complicated.
>>>>
>>>> Well, if someone else wants to take maintainership, feel free to over
>>>> take me :)
>>>
>>> Please let me know if I can help; I have a fair amount of experience
>>> with building and packaging GCC, but no so much with the internals.
>>>
>>
>> Actually neither do I, just enough to make minor changes.
>>
>>
>
> I've started looking at the patches, they definitely aren't trivial.
> I'll probably be releasing it as experimental.

There are local cygwin patches to gcc?

Re: GCC maintainer volunteer?

[JonY]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

On 2/21/2013 20:40, NightStrike wrote:
>> I've started looking at the patches, they definitely aren't trivial.
>> I'll probably be releasing it as experimental.
> 
> There are local cygwin patches to gcc?
> 

Yes, about 100KB of it. I confess I don't know what most of is for, my
understanding of the gcc internals are limited.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: GCC maintainer volunteer?

[Corinna Vinschen]

On Feb 21 21:33, JonY wrote:
> On 2/21/2013 20:40, NightStrike wrote:
> >> I've started looking at the patches, they definitely aren't trivial.
> >> I'll probably be releasing it as experimental.
> > 
> > There are local cygwin patches to gcc?
> > 
> 
> Yes, about 100KB of it. I confess I don't know what most of is for, my
> understanding of the gcc internals are limited.

I assume some (or all) of them are already upstream, but they were not
backported into the 4.5.x branch.  It might be a good idea to start out
with a clean upstream build and then look into the patches if they still
make some sense.


Corinna

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

Re: GCC maintainer volunteer?

[JonY]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

On 2/21/2013 21:42, Corinna Vinschen wrote:
> On Feb 21 21:33, JonY wrote:
>> On 2/21/2013 20:40, NightStrike wrote:
>>>> I've started looking at the patches, they definitely aren't trivial.
>>>> I'll probably be releasing it as experimental.
>>>
>>> There are local cygwin patches to gcc?
>>>
>>
>> Yes, about 100KB of it. I confess I don't know what most of is for, my
>> understanding of the gcc internals are limited.
> 
> I assume some (or all) of them are already upstream, but they were not
> backported into the 4.5.x branch.  It might be a good idea to start out
> with a clean upstream build and then look into the patches if they still
> make some sense.
> 

OK, will do.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: GCC maintainer volunteer?

[NightStrike]

On Thu, Feb 21, 2013 at 3:42 AM, Corinna Vinschen wrote:
> On Feb 21 21:33, JonY wrote:
>> On 2/21/2013 20:40, NightStrike wrote:
>> >> I've started looking at the patches, they definitely aren't trivial.
>> >> I'll probably be releasing it as experimental.
>> >
>> > There are local cygwin patches to gcc?
>> >
>>
>> Yes, about 100KB of it. I confess I don't know what most of is for, my
>> understanding of the gcc internals are limited.
>
> I assume some (or all) of them are already upstream, but they were not
> backported into the 4.5.x branch.  It might be a good idea to start out
> with a clean upstream build and then look into the patches if they still
> make some sense.

Are they in 4.6?  If so, why not just start fresh and clean with a 4.6
'chain that needs zero patching?

Re: GCC maintainer volunteer?

[Chris Sutcliffe]

On 21 February 2013 10:38, NightStrike wrote:
> On Thu, Feb 21, 2013 at 3:42 AM, Corinna Vinschen wrote:
>> On Feb 21 21:33, JonY wrote:
>>> On 2/21/2013 20:40, NightStrike wrote:
>>> >> I've started looking at the patches, they definitely aren't trivial.
>>> >> I'll probably be releasing it as experimental.
>>> >
>>> > There are local cygwin patches to gcc?
>>> >
>>>
>>> Yes, about 100KB of it. I confess I don't know what most of is for, my
>>> understanding of the gcc internals are limited.
>>
>> I assume some (or all) of them are already upstream, but they were not
>> backported into the 4.5.x branch.  It might be a good idea to start out
>> with a clean upstream build and then look into the patches if they still
>> make some sense.
>
> Are they in 4.6?  If so, why not just start fresh and clean with a 4.6
> 'chain that needs zero patching?

I believe Corinna means going to later version of GCC, preferably
straight to 4.7 would be great.

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

Re: GCC maintainer volunteer?

[Corinna Vinschen]

On Feb 21 11:31, Chris Sutcliffe wrote:
> On 21 February 2013 10:38, NightStrike wrote:
> > On Thu, Feb 21, 2013 at 3:42 AM, Corinna Vinschen wrote:
> >> On Feb 21 21:33, JonY wrote:
> >>> On 2/21/2013 20:40, NightStrike wrote:
> >>> >> I've started looking at the patches, they definitely aren't trivial.
> >>> >> I'll probably be releasing it as experimental.
> >>> >
> >>> > There are local cygwin patches to gcc?
> >>> >
> >>>
> >>> Yes, about 100KB of it. I confess I don't know what most of is for, my
> >>> understanding of the gcc internals are limited.
> >>
> >> I assume some (or all) of them are already upstream, but they were not
> >> backported into the 4.5.x branch.  It might be a good idea to start out
> >> with a clean upstream build and then look into the patches if they still
> >> make some sense.
> >
> > Are they in 4.6?  If so, why not just start fresh and clean with a 4.6
> > 'chain that needs zero patching?
> 
> I believe Corinna means going to later version of GCC, preferably
> straight to 4.7 would be great.

Exactly.  The question is then, what patches from the 4.5.3 gcc were
not applied upstream and still make sense today.


Corinna

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

Re: GCC maintainer volunteer?

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]

On 2/22/2013 00:59, Corinna Vinschen wrote:
> On Feb 21 11:31, Chris Sutcliffe wrote:
>> On 21 February 2013 10:38, NightStrike wrote:
>>> On Thu, Feb 21, 2013 at 3:42 AM, Corinna Vinschen wrote:
>>>> On Feb 21 21:33, JonY wrote:
>>>>> On 2/21/2013 20:40, NightStrike wrote:
>>>>>>> I've started looking at the patches, they definitely aren't trivial.
>>>>>>> I'll probably be releasing it as experimental.
>>>>>>
>>>>>> There are local cygwin patches to gcc?
>>>>>>
>>>>>
>>>>> Yes, about 100KB of it. I confess I don't know what most of is for, my
>>>>> understanding of the gcc internals are limited.
>>>>
>>>> I assume some (or all) of them are already upstream, but they were not
>>>> backported into the 4.5.x branch.  It might be a good idea to start out
>>>> with a clean upstream build and then look into the patches if they still
>>>> make some sense.
>>>
>>> Are they in 4.6?  If so, why not just start fresh and clean with a 4.6
>>> 'chain that needs zero patching?
>>
>> I believe Corinna means going to later version of GCC, preferably
>> straight to 4.7 would be great.
> 
> Exactly.  The question is then, what patches from the 4.5.3 gcc were
> not applied upstream and still make sense today.
> 

I have not looked at all the patches closely, but some of them were not
merged in gcc-4.7.2, at least the peflags patch did not.

Who is the upstream GCC maintainer for Cygwin anyway?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: GCC maintainer volunteer?

[marco atzeri]

On 2/21/2013 10:48 PM, JonY wrote:

> I have not looked at all the patches closely, but some of them were not
> merged in gcc-4.7.2, at least the peflags patch did not.
>
> Who is the upstream GCC maintainer for Cygwin anyway?

I would guess Dave Korn

Marco

Re: GCC maintainer volunteer?

[Christopher Faylor]

On Fri, Feb 22, 2013 at 05:48:20AM +0800, JonY wrote:
>Who is the upstream GCC maintainer for Cygwin anyway?

It's Dave Korn, Kai Tietz, and me.  I haven't been active for years
though.  If you have patches that you'd like to get in maybe Kai
could expedite that.

cgf

Re: GCC maintainer volunteer?

[Corinna Vinschen]

On Feb 22 00:21, Christopher Faylor wrote:
> On Fri, Feb 22, 2013 at 05:48:20AM +0800, JonY wrote:
> >Who is the upstream GCC maintainer for Cygwin anyway?
> 
> It's Dave Korn, Kai Tietz, and me.  I haven't been active for years
> though.  If you have patches that you'd like to get in maybe Kai
> could expedite that.

Kai's the right one, probably.  He will also probably take over the
64 bit Cygwin upstream GCC maintainership.


Corinna

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

Re: GCC maintainer volunteer?

[Yaakov]

On Thu, 21 Feb 2013 17:59:07 +0100, Corinna Vinschen wrote:
> Exactly.  The question is then, what patches from the 4.5.3 gcc were
> not applied upstream and still make sense today.

I have a copy of the patchset here with a few additions of my own:

http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc4;a=tree

classpath-0.98-*.patch: patches carried over from my port of GNU
Classpath; these are required.

config-rpath.patch: IIUC can be avoided with
--without-libiconv-prefix --without-libintl-prefix configure flags.

gcc45-ada.diff: switches Cygwin GNAT from a Windows hybrid to pure *NIX
code, and enable shared libgnat.  Last time I tried it, code linked with
the libgnat DLL didn't exit properly, so this may need more work.

gcc45-ehdebug.diff: just some debugging printf()s AFAICS.

gcc45-java-FIONREAD.diff: important fix a bug in NIO; this is a must.

gcc45-libffi.diff: makes FFI lib and header install in GCC dirs instead
of system dirs.  Perhaps this version shouldn't be installed at all
(only the convenience library is actually used in libjava) and ship the
standalone libffi-3.0.11 instead.

gcc45-libstdc.diff: The -no-undefined hunks are required, but the
-bindir flags aren't necessary with cygport.  -Wl,--enable-auto-import
is already the default, but it seems that is insufficient, hence all
the dllimport/dllexport.  Honestly I'm not sure why though.

gcc45-misc-core.diff: not sure what this is for.

gcc45-mnocygwin.diff: obsolete.

gcc45-peflags.diff: link only executables with --tsaware, and also use
--large-address-aware.  This too is a must.

gcc45-sig-unwind.diff: explained therein; may have been upstreamed
already.

gcc45-skiptest.diff: test is ELF-specific.

There is one more patch required from the Fedora Cygwin toolchain:

http://fedora-cygwin.git.sourceforge.net/git/gitweb.cgi?p=fedora-cygwin/cygwin-gcc;a=tree

gcc45-gc-win32-threads.diff: the native gcc4 was last built before
pthread_getaddr_np() was added, so this is a new requirement.

HTH,


Yaakov

Re: GCC maintainer volunteer?

[Corinna Vinschen]

On Feb 22 01:00, Yaakov wrote:
> On Thu, 21 Feb 2013 17:59:07 +0100, Corinna Vinschen wrote:
> > Exactly.  The question is then, what patches from the 4.5.3 gcc were
> > not applied upstream and still make sense today.
> 
> I have a copy of the patchset here with a few additions of my own:
> 
> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc4;a=tree
> [...]
> gcc45-peflags.diff: link only executables with --tsaware, and also use
> --large-address-aware.  This too is a must.

tsaware is upstream.  Not sure about --large-address-aware, though.  The
64 bit (where the flag doesn't make sense) compiler or linker sets this
flag by default, but I don't know about the 32 bit build.


Corinna

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

Re: GCC maintainer volunteer?

[JonY]

[-- Attachment #1: Type: text/plain, Size: 2549 bytes --]

On 2/22/2013 15:00, Yaakov (Cygwin/X) wrote:
> On Thu, 21 Feb 2013 17:59:07 +0100, Corinna Vinschen wrote:
>> Exactly.  The question is then, what patches from the 4.5.3 gcc were
>> not applied upstream and still make sense today.
> 
> I have a copy of the patchset here with a few additions of my own:
> 
> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc4;a=tree
> 
> classpath-0.98-*.patch: patches carried over from my port of GNU
> Classpath; these are required.
> 

Only classpath-0.98-build.patch applies.

> config-rpath.patch: IIUC can be avoided with
> --without-libiconv-prefix --without-libintl-prefix configure flags.
> 

Still applies.

> gcc45-ada.diff: switches Cygwin GNAT from a Windows hybrid to pure *NIX
> code, and enable shared libgnat.  Last time I tried it, code linked with
> the libgnat DLL didn't exit properly, so this may need more work.
> 
> gcc45-ehdebug.diff: just some debugging printf()s AFAICS.
> 
> gcc45-java-FIONREAD.diff: important fix a bug in NIO; this is a must.
> 
> gcc45-libffi.diff: makes FFI lib and header install in GCC dirs instead
> of system dirs.  Perhaps this version shouldn't be installed at all
> (only the convenience library is actually used in libjava) and ship the
> standalone libffi-3.0.11 instead.
> 
> gcc45-libstdc.diff: The -no-undefined hunks are required, but the
> -bindir flags aren't necessary with cygport.  -Wl,--enable-auto-import
> is already the default, but it seems that is insufficient, hence all
> the dllimport/dllexport.  Honestly I'm not sure why though.
> 
> gcc45-misc-core.diff: not sure what this is for.
> 

Does not currently apply.

> gcc45-mnocygwin.diff: obsolete.
> 

Noted.
> gcc45-peflags.diff: link only executables with --tsaware, and also use
> --large-address-aware.  This too is a must.
> 

Not upstream yet. Does not apply, but simple enough to fix.

> gcc45-sig-unwind.diff: explained therein; may have been upstreamed
> already.
> 

Does not apply.

> gcc45-skiptest.diff: test is ELF-specific.
> 

Still applies.
> There is one more patch required from the Fedora Cygwin toolchain:
> 
> http://fedora-cygwin.git.sourceforge.net/git/gitweb.cgi?p=fedora-cygwin/cygwin-gcc;a=tree
> 
> gcc45-gc-win32-threads.diff: the native gcc4 was last built before
> pthread_getaddr_np() was added, so this is a new requirement.
> 

OK, I'll look into that. I have not look closely how the patches fail to
apply, just took a glance at cygport prep output.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: GCC maintainer volunteer?

[JonY]

[-- Attachment #1: Type: text/plain, Size: 258 bytes --]


I feel I am missing something obvious here.

Dave's cygport references set-gcc-default-3.sh and set-gcc-default-4.sh
but never creates them...

I'll probably upload an experimental version soon-ish, once I can figure
out how the packaging work.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: GCC maintainer volunteer?

[Ken Brown]

On 2/23/2013 10:04 AM, JonY wrote:
>
> I feel I am missing something obvious here.
>
> Dave's cygport references set-gcc-default-3.sh and set-gcc-default-4.sh
> but never creates them...

They're created when gcc4-4.5.3-3.cygwin.patch is applied.

Ken

Re: GCC maintainer volunteer?

[JonY]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

On 2/23/2013 23:45, Ken Brown wrote:
> On 2/23/2013 10:04 AM, JonY wrote:
>>
>> I feel I am missing something obvious here.
>>
>> Dave's cygport references set-gcc-default-3.sh and set-gcc-default-4.sh
>> but never creates them...
> 
> They're created when gcc4-4.5.3-3.cygwin.patch is applied.
> 

After that, how does it get installed? cygport install package did not
seem to package it.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: GCC maintainer volunteer?

[Ken Brown]

On 2/23/2013 8:11 PM, JonY wrote:
> On 2/23/2013 23:45, Ken Brown wrote:
>> On 2/23/2013 10:04 AM, JonY wrote:
>>>
>>> I feel I am missing something obvious here.
>>>
>>> Dave's cygport references set-gcc-default-3.sh and set-gcc-default-4.sh
>>> but never creates them...
>>
>> They're created when gcc4-4.5.3-3.cygwin.patch is applied.
>>
>
> After that, how does it get installed? cygport install package did not
> seem to package it.

`cygport *.cygport install' puts it into ${D}/usr/bin because of the 
following snippet of the .cygport file:

src_install() {
[...]
	dobin ${C}/set-gcc-default-{3,4}.sh
[...]

And then `cygport *.cygport package' puts it into the tarball for gcc4-core:

gcc4_core_CONTENTS="--exclude=jni*.h
[...]
     usr/bin/set-gcc-default-3.sh \
     usr/bin/set-gcc-default-4.sh \
[...]

But isn't all this irrelevant for you?  There's no reason to keep gcc3 
around anymore, is there?

Ken

Re: GCC maintainer volunteer?

[JonY]

[-- Attachment #1: Type: text/plain, Size: 217 bytes --]

On 2/24/2013 09:39, Ken Brown wrote:

> But isn't all this irrelevant for you?  There's no reason to keep gcc3
> around anymore, is there?

I don't know, I'll leave that to the core Cygwin devs to decide.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: GCC maintainer volunteer?

[Christopher Faylor]

On Sun, Feb 24, 2013 at 10:01:56AM +0800, JonY wrote:
>On 2/24/2013 09:39, Ken Brown wrote:
>
>> But isn't all this irrelevant for you?  There's no reason to keep gcc3
>> around anymore, is there?
>
>I don't know, I'll leave that to the core Cygwin devs to decide.

I'd be happy to get rid of it but don't people still use it?  We can't
have the gcc4 package overwriting someone's gcc3 if so.

cgf

Re: GCC maintainer volunteer?

[Chris Sutcliffe]

Hi Dave,

As per this message:

http://cygwin.com/ml/cygwin/2013-02/msg00292.html

Are you back and still maintaining GCC?

Thanks,

Chris

Re: GCC maintainer volunteer?

[JonY]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On 2/24/2013 12:55, Christopher Faylor wrote:
> On Sun, Feb 24, 2013 at 10:01:56AM +0800, JonY wrote:
>> On 2/24/2013 09:39, Ken Brown wrote:
>>
>>> But isn't all this irrelevant for you?  There's no reason to keep gcc3
>>> around anymore, is there?
>>
>> I don't know, I'll leave that to the core Cygwin devs to decide.
> 
> I'd be happy to get rid of it but don't people still use it?  We can't
> have the gcc4 package overwriting someone's gcc3 if so.
> 

OK.

Anyway, packaging is taking longer than expected, still working on
packaging bugs.

I'm thinking of releasing a test version without Java, not all the
patches have been integrated yet.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: GCC maintainer volunteer?

[Christopher Faylor]

On Mon, Feb 25, 2013 at 10:40:04PM +0800, JonY wrote:
>On 2/24/2013 12:55, Christopher Faylor wrote:
>> On Sun, Feb 24, 2013 at 10:01:56AM +0800, JonY wrote:
>>> On 2/24/2013 09:39, Ken Brown wrote:
>>>
>>>> But isn't all this irrelevant for you?  There's no reason to keep gcc3
>>>> around anymore, is there?
>>>
>>> I don't know, I'll leave that to the core Cygwin devs to decide.
>> 
>> I'd be happy to get rid of it but don't people still use it?  We can't
>> have the gcc4 package overwriting someone's gcc3 if so.
>> 
>
>OK.
>
>Anyway, packaging is taking longer than expected, still working on
>packaging bugs.
>
>I'm thinking of releasing a test version without Java, not all the
>patches have been integrated yet.

Hmm.  We're in a unique situation here where Dave Korn seems to think
he's still the maintainer but isn't responding to email in cygwin-apps.

Dave, could you please respond to cygwin-apps?

cgf

Re: GCC maintainer volunteer?

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

On 2/25/2013 22:40, JonY wrote:
> On 2/24/2013 12:55, Christopher Faylor wrote:
>> On Sun, Feb 24, 2013 at 10:01:56AM +0800, JonY wrote:
>>> On 2/24/2013 09:39, Ken Brown wrote:
>>>
>>>> But isn't all this irrelevant for you?  There's no reason to keep gcc3
>>>> around anymore, is there?
>>>
>>> I don't know, I'll leave that to the core Cygwin devs to decide.
>>
>> I'd be happy to get rid of it but don't people still use it?  We can't
>> have the gcc4 package overwriting someone's gcc3 if so.
>>
> 
> OK.
> 
> Anyway, packaging is taking longer than expected, still working on
> packaging bugs.
> 
> I'm thinking of releasing a test version without Java, not all the
> patches have been integrated yet.
> 

I now have gcc4-4.7.2-1 built with all the patches integrated but Java
doesn't build, it is a separate issue. I'm hesitant to push it directly
to the download servers, might break things.

I've put the following in the hits file:
curr: 4.5.3-3
prev: 4.3.4-4
test: 4.7.2-1

Any staging areas or advice?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: GCC maintainer volunteer?

[Corinna Vinschen]

On Feb 27 20:05, JonY wrote:
> On 2/25/2013 22:40, JonY wrote:
> > On 2/24/2013 12:55, Christopher Faylor wrote:
> >> On Sun, Feb 24, 2013 at 10:01:56AM +0800, JonY wrote:
> >>> On 2/24/2013 09:39, Ken Brown wrote:
> >>>
> >>>> But isn't all this irrelevant for you?  There's no reason to keep gcc3
> >>>> around anymore, is there?
> >>>
> >>> I don't know, I'll leave that to the core Cygwin devs to decide.
> >>
> >> I'd be happy to get rid of it but don't people still use it?  We can't
> >> have the gcc4 package overwriting someone's gcc3 if so.
> >>
> > 
> > OK.
> > 
> > Anyway, packaging is taking longer than expected, still working on
> > packaging bugs.
> > 
> > I'm thinking of releasing a test version without Java, not all the
> > patches have been integrated yet.
> > 
> 
> I now have gcc4-4.7.2-1 built with all the patches integrated but Java
> doesn't build, it is a separate issue. I'm hesitant to push it directly
> to the download servers, might break things.
> 
> I've put the following in the hits file:
> curr: 4.5.3-3
> prev: 4.3.4-4
> test: 4.7.2-1
> 
> Any staging areas or advice?

Just upload the test release to the release area and write a TEST mail
to cygwin-announce.  Or is there anything special you'd like to do?


Corinna

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

Re: GCC maintainer volunteer?

[JonY]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

On 2/27/2013 21:10, Corinna Vinschen wrote
> 
> Just upload the test release to the release area and write a TEST mail
> to cygwin-announce.  Or is there anything special you'd like to do?
> 
> 

I'm worried that I might break gcc installs if I overlooked something
obvious.

The upload will be overwriting the .hint files, java and libffi are
empty packages (I could not get java to build yet). I can't figure out
how to pack the debuginfo package, it is always empty.

Will you be able to rollback my uploads in case something does go wrong?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: GCC maintainer volunteer?

[Corinna Vinschen]

On Feb 27 21:29, JonY wrote:
> On 2/27/2013 21:10, Corinna Vinschen wrote
> > 
> > Just upload the test release to the release area and write a TEST mail
> > to cygwin-announce.  Or is there anything special you'd like to do?
> > 
> > 
> 
> I'm worried that I might break gcc installs if I overlooked something
> obvious.
> 
> The upload will be overwriting the .hint files, java and libffi are
> empty packages (I could not get java to build yet).

I'm not concerend about java (dum di dum), but why is libffi missing?

> I can't figure out
> how to pack the debuginfo package, it is always empty.

Yaakov might be able to help here.

> Will you be able to rollback my uploads in case something does go wrong?

In theory, yes.  If you leave the dependencies in place for the "curr"
release, then the test release shouldn't interfere and testers will
have to care for the stuff themselves.  Let's assume for a start, that
downmloaders of a gcc test package know what they are doing.

Another way to distinguish the new gcc from the current on would be
perhaps to create a "gcc472" package set, distinct from the other gcc
packages.  It could install itself into /usr/local, just for the test
period.
Yeah, I know, I know, no official package should install into
/usr/local.  Maybe /opt would be fine for once, too.


Corinna

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

Re: GCC maintainer volunteer?

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1898 bytes --]

On 2/27/2013 21:59, Corinna Vinschen wrote:
> On Feb 27 21:29, JonY wrote:
>> On 2/27/2013 21:10, Corinna Vinschen wrote
>>>
>>> Just upload the test release to the release area and write a TEST mail
>>> to cygwin-announce.  Or is there anything special you'd like to do?
>>>
>>>
>>
>> I'm worried that I might break gcc installs if I overlooked something
>> obvious.
>>
>> The upload will be overwriting the .hint files, java and libffi are
>> empty packages (I could not get java to build yet).
> 
> I'm not concerend about java (dum di dum), but why is libffi missing?
> 

libffi only gets built when Java is enabled.

>> I can't figure out
>> how to pack the debuginfo package, it is always empty.
> 
> Yaakov might be able to help here.
> 

Hi Yaakov, I have gcc4_debuginfo_CONTENTS="usr/lib/debug/" in the
cygport file, any ideas?

>> Will you be able to rollback my uploads in case something does go wrong?
> 
> In theory, yes.  If you leave the dependencies in place for the "curr"
> release, then the test release shouldn't interfere and testers will
> have to care for the stuff themselves.  Let's assume for a start, that
> downmloaders of a gcc test package know what they are doing.
> 

Now this brings up a good question. libgnat4.5 became libgnat4.7 in
4.7.2, likewise for libobjc2 to libobjc4. So you are saying that I
should leave the runtime depends for 4.5.x?

> Another way to distinguish the new gcc from the current on would be
> perhaps to create a "gcc472" package set, distinct from the other gcc
> packages.  It could install itself into /usr/local, just for the test
> period.
> Yeah, I know, I know, no official package should install into
> /usr/local.  Maybe /opt would be fine for once, too.
> 

That might be a saner approach to testing. Do I need to use postinstall
to add it to PATH? If so, how do I do that?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: GCC maintainer volunteer?

[marco atzeri]

On 2/27/2013 11:23 PM, JonY wrote:
> On 2/27/2013 21:59, Corinna Vinschen wrote:
>> On Feb 27 21:29, JonY wrote:
>>> On 2/27/2013 21:10, Corinna Vinschen wrote
>>>>
>>>> Just upload the test release to the release area and write a TEST mail
>>>> to cygwin-announce.  Or is there anything special you'd like to do?
>>>>
>>>>
>>>
>>> I'm worried that I might break gcc installs if I overlooked something
>>> obvious.
>>>
>>> The upload will be overwriting the .hint files, java and libffi are
>>> empty packages (I could not get java to build yet).
>>
>> I'm not concerend about java (dum di dum), but why is libffi missing?
>>
>
> libffi only gets built when Java is enabled.
>
>>> I can't figure out
>>> how to pack the debuginfo package, it is always empty.
>>
>> Yaakov might be able to help here.
>>
>
> Hi Yaakov, I have gcc4_debuginfo_CONTENTS="usr/lib/debug/" in the
> cygport file, any ideas?
>
>>> Will you be able to rollback my uploads in case something does go wrong?
>>
>> In theory, yes.  If you leave the dependencies in place for the "curr"
>> release, then the test release shouldn't interfere and testers will
>> have to care for the stuff themselves.  Let's assume for a start, that
>> downmloaders of a gcc test package know what they are doing.
>>
>
> Now this brings up a good question. libgnat4.5 became libgnat4.7 in
> 4.7.2, likewise for libobjc2 to libobjc4. So you are saying that I
> should leave the runtime depends for 4.5.x?

yes, otherwise you break it for current
Put the test depends in the test announcement, so who want to test
will add by hand.

http://cygwin.com/ml/cygwin-apps/2012-11/msg00067.html

>
>> Another way to distinguish the new gcc from the current on would be
>> perhaps to create a "gcc472" package set, distinct from the other gcc
>> packages.  It could install itself into /usr/local, just for the test
>> period.
>> Yeah, I know, I know, no official package should install into
>> /usr/local.  Maybe /opt would be fine for once, too.
>>
>
> That might be a saner approach to testing. Do I need to use postinstall
> to add it to PATH? If so, how do I do that?

looks at:
/etc/profile.d/lapack0.csh
/etc/profile.d/lapack0.sh

>
>
Marco

Re: GCC maintainer volunteer?

[Yaakov]

On Wed, 27 Feb 2013 14:59:20 +0100, Corinna Vinschen wrote:
> On Feb 27 21:29, JonY wrote:
> > I'm worried that I might break gcc installs if I overlooked something
> > obvious.
> > 
> > The upload will be overwriting the .hint files, java and libffi are
> > empty packages (I could not get java to build yet).
> 
> I'm not concerend about java (dum di dum), but why is libffi missing?
> 
> > I can't figure out
> > how to pack the debuginfo package, it is always empty.
> 
> Yaakov might be able to help here.

Working on it.

> > Will you be able to rollback my uploads in case something does go wrong?
> 
> In theory, yes.  If you leave the dependencies in place for the "curr"
> release, then the test release shouldn't interfere and testers will
> have to care for the stuff themselves.  Let's assume for a start, that
> downmloaders of a gcc test package know what they are doing.
> 
> Another way to distinguish the new gcc from the current on would be
> perhaps to create a "gcc472" package set, distinct from the other gcc
> packages.  It could install itself into /usr/local, just for the test
> period.
> Yeah, I know, I know, no official package should install into
> /usr/local.  Maybe /opt would be fine for once, too.

The only way to really test GCC is to throw a lot of software at it and
see what breaks, and short of someone doing a mass rebuild, I'm not sure
that will happen unless it goes stable quickly.  I volunteered to put
4.5 through its paces, but it remained in testing for so long that Ports
almost ended up as a completely forked distro and it took me months to
clean up the mess afterwards.


Yaakov

Re: GCC maintainer volunteer?

[NightStrike]

On Thu, Feb 28, 2013 at 12:04 AM, Yaakov
<yselkowitz@users.sourceforge.net> wrote:
> On Wed, 27 Feb 2013 14:59:20 +0100, Corinna Vinschen wrote:
>> On Feb 27 21:29, JonY wrote:
>> > I'm worried that I might break gcc installs if I overlooked something
>> > obvious.
>> >
>> > The upload will be overwriting the .hint files, java and libffi are
>> > empty packages (I could not get java to build yet).
>>
>> I'm not concerend about java (dum di dum), but why is libffi missing?
>>
>> > I can't figure out
>> > how to pack the debuginfo package, it is always empty.
>>
>> Yaakov might be able to help here.
>
> Working on it.
>
>> > Will you be able to rollback my uploads in case something does go wrong?
>>
>> In theory, yes.  If you leave the dependencies in place for the "curr"
>> release, then the test release shouldn't interfere and testers will
>> have to care for the stuff themselves.  Let's assume for a start, that
>> downmloaders of a gcc test package know what they are doing.
>>
>> Another way to distinguish the new gcc from the current on would be
>> perhaps to create a "gcc472" package set, distinct from the other gcc
>> packages.  It could install itself into /usr/local, just for the test
>> period.
>> Yeah, I know, I know, no official package should install into
>> /usr/local.  Maybe /opt would be fine for once, too.
>
> The only way to really test GCC is to throw a lot of software at it and
> see what breaks, and short of someone doing a mass rebuild, I'm not sure
> that will happen unless it goes stable quickly.  I volunteered to put
> 4.5 through its paces, but it remained in testing for so long that Ports
> almost ended up as a completely forked distro and it took me months to
> clean up the mess afterwards.
>
>
> Yaakov

Does cygwin have an automatic package building machinery thing like
Fedora?  Fedora does mass rebuilds with mingw-w64 often, for instance.

Re: GCC maintainer volunteer?

[Yaakov]

On Thu, 28 Feb 2013 07:06:21 -1000, NightStrike wrote:
> Does cygwin have an automatic package building machinery thing like
> Fedora?  Fedora does mass rebuilds with mingw-w64 often, for instance.

No, we don't, and we haven't done a mass rebuild since 1.5.0 IIRC
(too long, IMO).


Yaakov

Re: GCC maintainer volunteer?

[Yaakov]

On Sat, 23 Feb 2013 23:55:43 -0500, Christopher Faylor wrote:
> I'd be happy to get rid of it but don't people still use it?  We can't
> have the gcc4 package overwriting someone's gcc3 if so.

For what exactly?  The only messages I have seen about it are those who
installed 'gcc' thinking it was the current version only to realize
they needed 'gcc4'.  No recent distro still supported 3.4, -mno-cygwin
has been completely replaced by mingw64-*-gcc, and any software
included in distributions that doesn't compile OOTB with 4.x will have
patches available from those distros.  I think it's past time to scrap
3.4.


Yaakov

Re: GCC maintainer volunteer?

[Corinna Vinschen]

On Mar  6 04:29, Yaakov wrote:
> On Sat, 23 Feb 2013 23:55:43 -0500, Christopher Faylor wrote:
> > I'd be happy to get rid of it but don't people still use it?  We can't
> > have the gcc4 package overwriting someone's gcc3 if so.
> 
> For what exactly?  The only messages I have seen about it are those who
> installed 'gcc' thinking it was the current version only to realize
> they needed 'gcc4'.  No recent distro still supported 3.4, -mno-cygwin
> has been completely replaced by mingw64-*-gcc, and any software
> included in distributions that doesn't compile OOTB with 4.x will have
> patches available from those distros.  I think it's past time to scrap
> 3.4.

FWIW, I agree.


Corinna

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

Re: GCC maintainer volunteer?

[Christopher Faylor]

On Wed, Mar 06, 2013 at 11:40:35AM +0100, Corinna Vinschen wrote:
>On Mar  6 04:29, Yaakov wrote:
>> On Sat, 23 Feb 2013 23:55:43 -0500, Christopher Faylor wrote:
>> > I'd be happy to get rid of it but don't people still use it?  We can't
>> > have the gcc4 package overwriting someone's gcc3 if so.
>> 
>> For what exactly?  The only messages I have seen about it are those who
>> installed 'gcc' thinking it was the current version only to realize
>> they needed 'gcc4'.  No recent distro still supported 3.4, -mno-cygwin
>> has been completely replaced by mingw64-*-gcc, and any software
>> included in distributions that doesn't compile OOTB with 4.x will have
>> patches available from those distros.  I think it's past time to scrap
>> 3.4.
>
>FWIW, I agree.

OK, no objections here.  You're right that it is probably causing more
problems than it is solving.

cgf