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

Mapped-time interface.

<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

IRC, OFTC, #debian-hurd, 2012-06-04

<youpi> pinotree: -lrt in libpthread is what is breaking glib2.0
<youpi> during ./configure it makes clock_gettime linked in, while at
  library link it doesn't
<youpi> probably for obscure reasons
<youpi> I'll have to disable it in debian

IRC, OFTC, #debian-hurd, 2012-06-05

<pinotree> youpi: i saw your message about the linking issues with
  pthread/rt; do you want me to provide a patch to switch clock_gettime →
  gettimeofday in libpthread?
<youpi> you mean switch it back as it was previously?
<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 [BZ #14304], sourceware [BZ #14743], id:"CAH6eHdQRyTgkXE7k+UVpaObNTOZf7QF [email protected]", commit 6e6249d0b461b952d0f544792372663feb6d792a (2012-10-24).