summaryrefslogtreecommitdiff
path: root/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
diff options
context:
space:
mode:
authorSamuel Thibault <samuel.thibault@ens-lyon.org>2012-12-30 00:36:20 +0100
committerSamuel Thibault <samuel.thibault@ens-lyon.org>2012-12-30 00:36:20 +0100
commite9235e964397bc2c5c6ca1858aba5c098b591660 (patch)
treef105012a160e801e96ec81f2d26b447deb835d08 /open_issues/libpthread_CLOCK_MONOTONIC.mdwn
parentd90af7499de9d0c58215691174826f956ff6612c (diff)
parent55ffc6f5698b61c75260ff12b2591e3032b0651e (diff)
Merge branch 'master' of git.savannah.gnu.org:/srv/git/hurd/web
Diffstat (limited to 'open_issues/libpthread_CLOCK_MONOTONIC.mdwn')
-rw-r--r--open_issues/libpthread_CLOCK_MONOTONIC.mdwn39
1 files changed, 39 insertions, 0 deletions
diff --git a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
index 2c8f10f8..5a99778b 100644
--- a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
+++ b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
@@ -76,3 +76,42 @@ 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 :)
+
+[[!sourceware_PR 14304]], [[!sourceware_PR 14743]], [[!message-id
+"CAH6eHdQRyTgkXE7k+UVpaObNTOZf7QF_fNoU-bqbMhfzXxXUDg@mail.gmail.com"]], commit
+6e6249d0b461b952d0f544792372663feb6d792a (2012-10-24).