http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #29 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-03-08 22:38:49 UTC --- (In reply to comment #28) > (In reply to comment #26) > > Tru64 UNIX doesn't support weak undefined symbols, which seems to be > > what weakrefs are. > > Hmm, I think it is going to be difficult. What we want to have: > > a) If libc has clock_gettime, use it unconditionally > b) If librt has clock_gettime and weak refs are supported, use it if > available > c) If librt has it, but no weak refs are supported, don't use it. > d) If it not available at all, don't use it. Yes, sounds like a good plan. > (b) and (d) work; also (a) works - albeit with a warning. Now one needs to > support (c). Indeed; the patch was developed based on the understanding that only Linux has clock_gettime in librt, and Linux supports weakrefs, so (c) does not need to be considered. Oh well. > I think the best would be to set (effectively) HAVE_CLOCK_GETTIME > to false. > > One possibility would be to replace: > > #ifdef HAVE_CLOCK_GETTIME > # ifdef SUPPORTS_WEAK > ... > # else > > by > > #if define(HAVE_CLOCK_GETTIME) && define(SUPPORTS_WEAK) > > That would exclude platforms, where libc supports clock_gettime but which do > not have weak refs. Another possibility is a link-time check which does not > work well for some cross-compilations. > > What do you think? I think the easiest way would be to change the test in configure.ac where we check for clock_gettime in librt, so that we set, say, HAVE_CLOCK_GETTIME_LIBRT instead of HAVE_CLOCK_GETTIME, thus allowing us to distinguish whether the function a) exists at all b) is in libc or librt. That being said, I'd prefer to postpone this fix to stage 1 due to - I'm currently moving flats so my stuff is all over and I'm very busy - AFAIU 4.6 release is imminent? - I lack the ability to test all weird and wonderful targets. - This close to release I'd very much like to avoid regressions in primary or secondary targets. - As can be seen in the reopening of this PR, for less used targets there might anyway be a month latency between something landing in trunk and getting test reports. Thus, I'd suggest fixing this in stage 1, then, after getting reports that the fix works, backport hopefully in time for 4.6.1. Of course, the above is only my own justifications and constraints; if someone else wants to fix it ASAP, go right ahead.
