1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
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
|
