------- Comment #42 from iains at gcc dot gnu dot org 2010-04-13 01:07 ------- actually,
The logic in libgcc_s/libgcc_ext is working properly - libgcc_s.10.5 => /usr/libgcc_s.1.dylib => /usr/libSystem.dylib. The function is named in /usr/lib/libgcc_s.10.5. What is happening is Bad [at least IMO]; we have a "catch-all" -lgcc at the end of each REAL_LIBGCC_SPEC line - which I'm itching to remove (because, basically, it should not be necessary). In the case of the 'working - by removing lm' what seems to be happening is that the function is being picked up from the the static libgcc.a from that catch-all. in fact, the cases should fail regardless of -lm - since the function should be sourced from the system-library via the libgcc_s.10.5 stubs. [FWIW the libgcc_s.10.5 stubs should also be removed for D10 - since they don't add anything (except consumption of time) to the exercise.] I dunno: I realize that people would prefer tests to pass - but I worry about the tortuous way in which we are layering libraries (I'd really like to get rid of the catch-all -lgcc) [although it could always be applied temporarily ahead of the -lSystem in the LIB_SPEC for D10]. I guess the Right Thing is to XFAIL that test until the system lib is fixed... We should still control the use/placement of -lm --- I've not changed opinion on that. And we should still file a "-lm not needed on Darwin" with Dejagnu (in spite of nothing likely to happen quickly). A user who REALLY wants the functions from libgcc.a can always put it on the cl. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
