Re: darwin, symbol visibility differences between libgcc_s and libgcc

[IainS]

On 20 Dec 2008, at 03:51, Mike Stump wrote:


Yes, libgcc_s is carefully built with carefully controlled exports.  
They are controlled by:


  gcc/libgcc-std.ver

when someone wants to export one of the symbols, they can just add  
it to the list.


OK, my question was phrased poorly;
I understand the mechanism - what I don't understand is the rationale.

What is the benefit of splitting the publicly exported symbols  
between libgcc_s.1.dylib and libgcc.a?


This forces us to -lgcc, even in a hypothetical newly-released case,  
where the libgcc_s.1.dylib is completely up-to-date.


Iain

Closing 4.2 branch

[Joseph S. Myers]

As no volunteers to produce a further 4.2 release or releases have come 
forward since the last status report 
, I propose to close the 
4.2 branch after 4.4 is branched and all the steps in the branching 
checklist  have been completed for 4.4.  
This seems likely to be some time in January.

This means disabling snapshots and nightly DATESTAMP updates for the 
branch, closing bugs that are open as 4.2 regressions but fixed in 4.3, 
4.4 and 4.5, and removing "4.2/" from the summaries of 4.2 regression bugs 
that remain open as also being regressions in future releases.  In each 
case, the milestones will be updated accordingly if presently set to a 4.2 
release (remember the milestone of a closed bug represents the version in 
which it was fixed), as will the "known to work" and "known to fail" 
information.

If anyone wishes to produce one or more further releases from 4.2 branch 
before it is closed, and to carry out the closing process after making 
those releases (which takes several hours to interpret the bug report logs 
of hundreds of bugs as to what if any release the bug is completely fixed 
in), they should volunteer now.  I think the SC will then need to approve 
them as a 4.2 release manager.

-- 
Joseph S. Myers
jos...@codesourcery.com

bootstrap in mingw32

[gcchelp . 5 . adept]

Hi list,
I was getting a hell to compile any recent GCC under Windows mingw32 
(including GCC 4.3.2 as well as any 4.4 snapshot).

The tar command always gave errors.
I now found the solution, I needed to set

   build_install_headers_dir=install-headers-cp

in the config.build script in the branch where the *-mingw32-* is detected.

Could somebody consider changing this in the source tree?
Thanks!