IRC.

1 files changed, 27 insertions, 0 deletions

diff --git a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
index 2c8f10f8..86a613d3 100644
--- a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
+++ b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
@@ -76,3 +76,30 @@ 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