Reini Urban wrote: > About the shared libgcc: > Since this problem will not go away until we decide to keep the old and slow > WINAPI compatible SJLJ (hopefully not), we can just add this libgcc as > Base package. > Similar to the msvcrt.dll in the windows world.
That would be fine if it were even possible to build a shared libgcc. FSF gcc won't even do this, nor will it build shared libstdc++, etc. MinGW's gcc 4.2 has a humongous local patch that backports a bunch of stuff from 4.3 as well as using an ugly kludge to build shared libgcc. I can't speak for Dave or whoever else will spend time maintaining the Cygwin gcc packages, but I can say that if the past is any indication, maintaining a huge local out-of-tree patch is a giant pain and causes a) releases/updates to be slow or nonexistant and b) maintainers to not want to continune doing their thing. It's for these reasons that I think we really need to wait until these issues are fixed upstream so that we do not repeat what occured with the 3.x series, wherein we have currently have a set of local patches that are 548KB with a diffstat of: 154 files changed, 4884 insertions(+), 1669 deletions(-). (And those numbers don't include all the additions for adding the out-of-tree languages D and Pascal, so the actual changes are even greater.) Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/