[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

["jb at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #34 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-03-14 11:42:47 UTC ---
(In reply to comment #31)
> > 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.
> 
> Not really: the delay was caused because the test system broke and it
> took me quite some time to get myself a replacement.  Normally, I
> bootstrap everywhere once a week and analyse results.

Ok, that's nice to hear. Of course, it doesn't change the fact that this time
it did take a month, and, one might add, at almost the worst possible moment.
;)

> > 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.
> 
> I'd really like to see this fixed before 4.6.0: it is a regression from
> 4.5 and makes fortran completely unusable on Tru64 UNIX for a relatively
> minor gain on other platforms.

Well, do we really have any actual gfortran users on Tru64? Whereas a
high-resolution monotonic clock, while admittedly not a huge feature per se, is
something that is now available to gfortran users on some rather more popular
platforms.

>  If all else fails, I'd go as far as
> advocating to revert the patch that introduced clock_gettime

There has been a number of patches in this area more or less related to
clock_gettime, so IMHO fixing it properly is simpler and less prone to
introduce new regressions. My previous message in this PR hopefully does
exactly this and introduces a patch which should fix it along the lines
previously discussed. As my normal gcc development machine is packed in a box,
I haven't been able to test it. Also, note that it won't apply cleanly as the
paths are messed up (but the contents should otherwise apply fine). 

As I mentioned previously, I'd prefer to commit it after the 4.6 release, but
if the reviewer(s) feel it's safe I'm fine with getting it in for 4.6.

> (and quite
> late in the release cycle, I might say).

Yes, it started out as a simple patch which turned into a morass of
system-dependent stuff wrt. where clock_gettime lives and various levels of
weakref support. Sorry about that.