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
|
[[!meta copyright="Copyright © 2010 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]]."]]"""]]
bug-hurd discussion.
---
IRC, #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
|
