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
|
[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]]
[[!tag open_issue_glibc open_issue_hurd]]
[[!toc]]
# bug-hurd discussion.
# IRC, freenode, #hurd, 2010-08-12
<jkoenig> Looking at hurd.git, shouldn't {hurd,include}/Makefile's "all"
target do something, and shouldn't pretty much everything depend on them?
As it stands it seems that the system headers are used and the
potentially newer ones never get built, except maybe on "install" (which
is seemingly never called from the top-level Makefile)
<jkoenig> I would fix it, but something tells me that maybe it's a feature
:-)
<antrik> jkoenig: the headers are provided by glibc, along with the stubs
<jkoenig> antrik, you mean, even those built from the .defs files in hurd/
?
<antrik> yes
<jkoenig> oh, ok then.
<antrik> as glibc provides the stubs (in libhurduser), the headers also
have to come from there, or they would get out of sync
<jkoenig> hmm, shouldn't glibc also provide /usr/share/msgids/hurd.msgids,
then?
<antrik> jkoenig: not necessarily. the msgids describe what the servers
actually understand. if the stubs are missing from libhurduser, that's no
reason to leave out the msgids...
<jkoenig> ok this makes sense
# IRC, OFTC, #debian-hurd, 2011-09-29
<tschwinge> pinotree: I don't like their existence. IMO (but I haven't
researched this in very much detail), every user of RPC stubs should
generated them for themselves (and glibc should directly include the
stubs it uses internally).
<pinotree> sounds fair
<pinotree> maybe they could be moved from glibc to hurd?
<tschwinge> pinotree: Yeah; someone needs to research why we have them (or
if it's only convenience), and whether we want to keep them.
<pinotree> you could move them to hurd, leaving them unaltered, so binary
compatibility with eventual 3rd party users is not broken
<pinotree> but those using them, other than hurd itself, won't compile
anymore, so you fix them progressively
|
