diff options
Diffstat (limited to 'open_issues/glibc')
| -rw-r--r-- | open_issues/glibc/0.4.mdwn | 77 | ||||
| -rw-r--r-- | open_issues/glibc/t/tls.mdwn | 2 |
2 files changed, 1 insertions, 78 deletions
diff --git a/open_issues/glibc/0.4.mdwn b/open_issues/glibc/0.4.mdwn deleted file mode 100644 index 33ef8f3a..00000000 --- a/open_issues/glibc/0.4.mdwn +++ /dev/null @@ -1,77 +0,0 @@ -[[!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 diff --git a/open_issues/glibc/t/tls.mdwn b/open_issues/glibc/t/tls.mdwn index eba2b88b..b10703fd 100644 --- a/open_issues/glibc/t/tls.mdwn +++ b/open_issues/glibc/t/tls.mdwn @@ -71,7 +71,7 @@ After commit a9538892adfbb9f092e0bb14ff3a1703973968af, it's <youpi> have you had a look at the tls.pdf from Uli ? <youpi> all the gory details are there :) -Commit c61b4d41c9647a54a329aa021341c0eb032b793e, [[sourceware_PR 15754]], adds +Commit c61b4d41c9647a54a329aa021341c0eb032b793e, [[!sourceware_PR 15754]], adds `sysdeps/i386/stackguard-macros.h:POINTER_CHK_GUARD`, which is not correct for us (at the moment), but it also shouldn't cause any harm, as this file is only used in `elf/tst-ptrguard1.c` and `elf/tst-stackguard1.c`, which now will fail |