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
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
[[!meta copyright="Copyright © 2012, 2013, 2014 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_libpthread]]
Things to consider doing when bumping the glibc SONAME.
There are some comments in the sources, for example `hurd/geteuids.c`: `XXX
Remove this alias when we bump the libc soname.`
[[!toc]]
# IRC, freenode, #hurd, 2012-12-14
In context of [[packaging_libpthread]]/[[libpthread]].
<pinotree> once libc is switched internally from cthreads to pthreads (thus
breaking its BC), may be worth cleanup the hurd-specific exported symbols
<tschwinge> pinotree: Yes. If you already have ideas about what to clean
up, feel free to add a new page or a section on open_issues/glibc.
<pochu> we're gonna break backwards compatibility in glibc on hurd? that
could be the perfect moment to fix the /dev/fd/N problem without adding
new RPCs, though we'd probably have to break backwards-compatibility in
the exec server IIRC...
<tschwinge> pochu: Oh, I have to re-read that discussion, but thanks for
reminding!
[[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id
"4BFA500A.7030502@gmail.com"]].
# `time_t` -- Unix Epoch vs. 2038
## IRC, freenode, #hurd, 2013-12-12
<azeem> because it gets discussed in #debian-devel for the Linux i386
architecture right now: what's the deal with hurd-i386 and the 32bit
epoch overflow in 2038?
<braunr> what do you mean ?
<azeem> braunr: http://lwn.net/Articles/563285/
<braunr> ok but what do you mean ?
<braunr> i don't think there is anything special with the hurd about that
<azeem> well, time_t is 64bit on amd64 AIUI
<braunr> it's a signed long
<azeem> so maybe the Hurd guys were clever from the start
<azeem> k, k
<braunr> our big advantage is that we can afford to break things a little
without too much trouble
<braunr> in a system at work, we use unsigned 32-bit words
<braunr> which overflows in 2106
<braunr> and we already include funny comments that predict our successors,
if any, will probably fail to deal with the problem until short before
the overflow :>
<azeem> luckily, no nuclear reactors are running the Hurd sofar
<braunr> i wonder how the problem will be dealt with though
<braunr> ah, openbsd decided to break their abi
<azeem> yeah
<braunr> that's probably the simplest solution
<azeem> "just recompile"
<braunr> and they can afford it too
<azeem> yeah
<braunr> good to see people actually worry about it
<azeem> I guess people are getting worried about where Linux embedded is
being put into
<braunr> they're right about that
<azeem> "Please, don't fix the 2038 year issue. I also want to have some
job security :)"
<braunr> haha
|
