1 files changed, 58 insertions, 0 deletions
diff --git a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
new file mode 100644
index 00000000..f9195540
--- /dev/null
+++ b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
@@ -0,0 +1,58 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!meta title="libpthread: CLOCK_MONOTONIC"]]
+
+[[!tag open_issue_glibc open_issue_libpthread]]
+
+[[!message-id "201204220058.37328.toscano.pino@tiscali.it"]]
+
+
+# IRC, freenode, #hurd- 2012-04-22
+
+    <pinotree> youpi: what i thought would be creating a
+      glib/hurd/hurdtime.{c,h}, adding _hurd_gettimeofday and
+      _hurd_clock_{gettime,settime,getres} to it and making the current .c in
+      sysdeps call those
+    <youpi> yep
+    <youpi> that's unfortunate, but that's what nptl actually does
+    <pinotree> this way we could add inside hurdtime.c the mapped time stuff
+      too
+    <pinotree> most probably a noobish question, but why does rt link to
+      pthread?
+    <youpi> no idea :)
+    <youpi> possibly due to aio implementation
+    <youpi> ./sysdeps/pthread/aio_cancel.c
+    <youpi> probably due to that
+    <youpi> (and others)
+
+
+## IRC, freenode, #hurd- 2012-04-23
+
+    <youpi> pinotree: about librt vs libpthread, don't worry too much for now
+    <youpi> libpthread can lib against the already-installed librt
+    <youpi> it does work
+    <pinotree> youpi: wouldn't that cause a dependency loop?
+    <youpi> pinotree: what dependency loop?
+    <pinotree> youpi: librt wouldd link to pthread, no?
+    <youpi> and ?
+    <youpi> I don't think it's an issue that .so link with each other
+    <pinotree> it isn't?
+    <youpi> well, try
+    * pinotree never did that
+    <youpi> but I don't think it will pose problem
+    <youpi> well, perhaps initialization order
+    <youpi> anyway, I now have packages built, I'll test that
+    <youpi> pinotree: ok, it seems it doesn't work indeed :)
+    <youpi> early in initialization
+    <youpi> pinotree: the initialization bug might actually not be due to librt
+      at all
+    <youpi> pinotree: yes, things work even with -lrt
+    <pinotree> wow