[[!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 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 yep that's unfortunate, but that's what nptl actually does this way we could add inside hurdtime.c the mapped time stuff too most probably a noobish question, but why does rt link to pthread? no idea :) possibly due to aio implementation ./sysdeps/pthread/aio_cancel.c probably due to that (and others) ## IRC, freenode, #hurd- 2012-04-23 pinotree: about librt vs libpthread, don't worry too much for now libpthread can lib against the already-installed librt it does work youpi: wouldn't that cause a dependency loop? pinotree: what dependency loop? youpi: librt wouldd link to pthread, no? and ? I don't think it's an issue that .so link with each other it isn't? well, try * pinotree never did that but I don't think it will pose problem well, perhaps initialization order anyway, I now have packages built, I'll test that pinotree: ok, it seems it doesn't work indeed :) early in initialization pinotree: the initialization bug might actually not be due to librt at all pinotree: yes, things work even with -lrt wow