Re: Requesting maintainership for Cygwin and mingw-w64 ports
On Jun 2 18:18, JonY wrote: > Hello, > > I'd like to apply for the position of Cygwin and mingw-w64 gcc port > maintainer. What do I need to do to accomplish that? This sounds like a good idea to me, given that Jon is Cygwin distro maintainer for the native as well as the mingw-w64 cross toolchains for quite some time. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat signature.asc Description: PGP signature
Newlib/Cygwin now under GIT
Hi fellow developers, I'm happy to inform you that the move of Newlib/Cygwin from the src CVS repository to the new, combined GIT repository is now final. Here's how to access the new GIT repository: Read-only: git clone git://sourceware.org/git/newlib-cygwin.git Read/Write: git clone sourceware.org:/git/newlib-cygwin.git Web view: https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git Commit messages go to the newlib-cvs and/or cygwin-cvs mailing lists, just as before. Commit messages also create a message to the freenode IRC channel #cygwin-developers. If you find problems, don't hesitate to report them, preferredly on the mailing list newlib AT sourceware DOT org I'm not a git wizard, rather a wizzard (pardon the discworld reference) so help in case of problems is highly appreciated. Newlib list: Jeff is on the road for the next couple of days so a discussion of this point has to wait a while, but for the time being, patches should continue to be accompanied by a ChangeLog entry. Have fun, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat pgpD7U2UcjwY6.pgp Description: PGP signature
Re: Newlib/Cygwin now under GIT
On Mar 10 11:20, Joel Sherrill wrote: > Thank you for doing this! It cloned for me on the first try. > > Any particular reason, the repo is called newlib-cygwin.git > and not the more general newlib.git. Cygwin isn't the > only user of newlib. No, but Cygwin is part of the repo. It's a *combined* repo. Along the same lines the Cygwin folks might ask why it's not called cygwin.git or cygwin-newlib.git. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat pgpKtmhvzQzmy.pgp Description: PGP signature
Re: Newlib/Cygwin now under GIT
On Mar 10 17:03, Joseph Myers wrote: > On Tue, 10 Mar 2015, Corinna Vinschen wrote: > > > Hi fellow developers, > > > > > > I'm happy to inform you that the move of Newlib/Cygwin from the src CVS > > repository to the new, combined GIT repository is now final. > > I note that this repository includes the include/ directory, in its larger > binutils-gdb form rather than the smaller GCC form. > > How much of this is actually relevant for newlib? Keep in mind that this is a combined repo for newlib and Cygwin. Cygwin needs include/ for its dumper tool, which is a helper to create core files readable by GDB. It includes bfd.h elf/common.h elf/external.h and all files included by those. > Mostly it relates to > libiberty and object file formats, for use of code that's not included in > this repository (which does not include libiberty). If little or none of > this code is actually used in newlib, it might make sense to remove the > unused files so it's clear they do not need merging from the other > repositories. Of course, I have no problems to remove unused files, just not now. I'm still looking for a small problem in the repo, so please no unsolicited pushes for now. > (Apart from include/, various shared toplevel files and directories are > out of sync between the three repositories - GCC, binutils-gdb, > newlib-cygwin - and could do with someone identifying unmerged changes and > applying them to the repositories missing them.) This is a common problem. I guess newlib/cygwin got the oldest set and, afaik, the GCC toplevel stuff is kind of the master. It would be nice if we had some automatism in place to keep all former src repos in sync. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp32Rp5q6RAm.pgp Description: PGP signature
Re: Newlib/Cygwin now under GIT
[Somehow I managed to drop newlib from the recipient list. Re-added] On Mar 10 19:19, Corinna Vinschen wrote: > On Mar 10 17:03, Joseph Myers wrote: > > On Tue, 10 Mar 2015, Corinna Vinschen wrote: > > > > > Hi fellow developers, > > > > > > > > > I'm happy to inform you that the move of Newlib/Cygwin from the src CVS > > > repository to the new, combined GIT repository is now final. > > > > I note that this repository includes the include/ directory, in its larger > > binutils-gdb form rather than the smaller GCC form. > > > > How much of this is actually relevant for newlib? > > Keep in mind that this is a combined repo for newlib and Cygwin. Cygwin > needs include/ for its dumper tool, which is a helper to create core > files readable by GDB. It includes > > bfd.h > elf/common.h > elf/external.h > > and all files included by those. > > > Mostly it relates to > > libiberty and object file formats, for use of code that's not included in > > this repository (which does not include libiberty). If little or none of > > this code is actually used in newlib, it might make sense to remove the > > unused files so it's clear they do not need merging from the other > > repositories. > > Of course, I have no problems to remove unused files, just not > now. I'm still looking for a small problem in the repo, so please > no unsolicited pushes for now. The problems in the repo are fixed. If you had a problem accessing the repo in the last couple of minutes, it was me moving the problematic repo out and a repaired repo back into place. Sorry about that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpWuZvkD6blj.pgp Description: PGP signature
gcc 4.2 breaks debugging anonymous namespace
2>: Abbrev Number: 6 (DW_TAG_formal_parameter) DW_AT_name: i DW_AT_decl_file : 1 DW_AT_decl_line : 7 DW_AT_type: DW_AT_location: 2 byte block: 91 0 (DW_OP_fbreg: 0) <1>: Abbrev Number: 7 (DW_TAG_base_type) DW_AT_byte_size : 4 DW_AT_encoding: 5 (signed) DW_AT_name: int <1>: Abbrev Number: 8 (DW_TAG_variable) DW_AT_specification: <96> DW_AT_location: 5 byte block: 3 4 0 0 0(DW_OP_addr: 4) <1>: Abbrev Number: 9 (DW_TAG_namespace) DW_AT_name: A DW_AT_decl_file : 1 DW_AT_decl_line : 1 DW_AT_sibling : <109> <2>: Abbrev Number: 10 (DW_TAG_variable) DW_AT_name: a DW_AT_decl_file : 1 DW_AT_decl_line : 2 DW_AT_MIPS_linkage_name: _ZN1A1aE DW_AT_type: DW_AT_external: 1 DW_AT_declaration : 1 <1><109>: Abbrev Number: 8 (DW_TAG_variable) DW_AT_specification: DW_AT_location: 5 byte block: 3 0 0 0 0(DW_OP_addr: 0) b shows up in .debug_info, now expectedly so. But again it shows up without a DW_AT_MIPS_linkage_name row. So, in this testcase GDB again has no chance to recognize this b in the .debug_info and _ZN19_GLOBAL__N__ZN1A1aE1bE in the symbol table meaning the same symbol. IMHO, this is a bug in g++. The mangled name in DW_AT_MIPS_linkage_name is required so that GDB can correctly recognize mangled c++ symbols. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
