diff options
Diffstat (limited to 'open_issues/libpthread_CLOCK_MONOTONIC.mdwn')
| -rw-r--r-- | open_issues/libpthread_CLOCK_MONOTONIC.mdwn | 35 |
1 files changed, 35 insertions, 0 deletions
diff --git a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn index 2c8f10f8..22b2cd3b 100644 --- a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn +++ b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn @@ -76,3 +76,38 @@ License|/fdl]]."]]"""]] <pinotree> kind of, yes <youpi> I have reverted the change in libc for now <pinotree> ok + + +## IRC, freenode, #hurd, 2012-07-22 + + <tschwinge> pinotree, youpi: I once saw you discussing issue with librt + usage is libpthread -- is it this issue? http://sourceware.org/PR14304 + <youpi> tschwinge: (librt): no + <youpi> it's the converse + <pinotree> tschwinge: kind of + <youpi> unexpectedly loading libpthread is almost never a problem + <youpi> it's unexpectedly loading librt which was a problem for glib + <youpi> tschwinge: basically what happened with glib is that at configure + time, it could find clock_gettime without any -lrt, because of pulling + -lpthread, but at link time that wouldn't happen + + +## IRC, freenode, #hurd, 2012-07-23 + + <braunr> pinotree: oh, i see you changed __pthread_timedblock to use + clock_gettime + <braunr> i wonder if i should do the same in libthreads + <pinotree> yeah, i realized later it was a bad move + <braunr> ok + <braunr> i'll stick to gettimeofday for now + <pinotree> it'll be safe when implementing some private + __hurd_clock_get{time,res} in libc proper, making librt just forward to + it and adapting the gettimeofday to use it + + +## IRC, freenode, #hurd, 2012-10-22 + + <pinotree> youpi: apparently somebody in glibc land is indirectly solving + our "libpthread needs lirt which pulls libphtread" circular issue by + moving the clock_* functions to libc proper + <youpi> I've seen that yes :) |