diff options
Diffstat (limited to 'open_issues/glibc')
| -rw-r--r-- | open_issues/glibc/debian.mdwn | 39 | ||||
| -rw-r--r-- | open_issues/glibc/t/tls-threadvar.mdwn | 40 |
2 files changed, 78 insertions, 1 deletions
diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn index 9886ec98..2ef2c474 100644 --- a/open_issues/glibc/debian.mdwn +++ b/open_issues/glibc/debian.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2013 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 @@ -24,6 +24,43 @@ locale stuff. `--disable-compatible-utmp`? +## IRC, freenode, #hurd, 2013-08-28 + + <youpi> uh, the i686 profiles have much more progression than i386 + <youpi> it seems they don't actually run these + <pinotree> youpi: what do you mean with "we don't run those"? + <pinotree> iirc there are three build profiles done, but there are 4 + regression test files + <youpi> yes, but some failing tests are not run in the three build profiles + <youpi> even if they are built for all of them + <pinotree> not even run? which ones? + <youpi> see for instance test-ifloat.out + <youpi> test-ifloat is built in all profiles, but only run in the libc one + <pinotree> don't have a glibc built tree around atm, sorry :/ + <youpi> perhaps because glibc thinks it's not useful to run it again if it + fails on i386 + <youpi> you can check the logs + <pinotree> do you think glibc's build system is that smart? :) + <pinotree> all the builds are done in separate builddirs, so theorically + they should not touch each other... + <youpi> yes + <youpi> that's why I'm surprised + <pinotree> could it be they get not run in optimized/particular builds? + <pinotree> what about linux/kfreebsd i386? + <youpi> I don't see what makes them not run + <youpi> or at least be treated particularly by th eMakefile + <youpi> not run on kfreebsd either + <youpi> pinotree: also, most of the tests now working have been marked as + failing by your patches for 2.17, would it be possible to retry them on + the box you used at that time? + <pinotree> that's the vm on my machine + <youpi> which kind of vm? + <youpi> kvm? + <pinotree> y + <youpi> they are working here + <youpi> with kvm + + # Building Run `debian/rules patch` to apply patches (instead of having it done during the diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn index 609d866b..7ce36f41 100644 --- a/open_issues/glibc/t/tls-threadvar.mdwn +++ b/open_issues/glibc/t/tls-threadvar.mdwn @@ -76,3 +76,43 @@ dropped altogether, and `__thread` directly be used in glibc. <youpi> tschwinge: yes, there were a lot other occurences of threadvars stuff in various places <youpi> I'm building libc again, and will see what issue would remain + + +## IRC, freenode, #hurd, 2013-07-12 + + <youpi> braunr: about the per-thread ports, there is also the mig reply + port + <youpi> (stored in _HURD_THREADVAR_MIG_REPLY) + + +## IRC, freenode, #hurd, 2013-07-15 + + <braunr> and with the branch youpi pushed where he removes threadvars, it + shouldn't get "too" hard + <braunr> (save for the tricky bugs you may encounter) + <youpi> well, that branch is not working yet + + +## IRC, OFTC, #debian-hurd, 2013-09-22 + + <youpi> I'm currently tracking bugs with my threadvars changes + <youpi> some of them seem fine, others, not + <youpi> of course the most complex ones are the most probable culprits for + the issues I'm getting + <youpi> fortunately they're after the process bootstrap + <youpi> so basically that works + <youpi> just a few dozen tests fail + <youpi> mostly about loading .so or raising signals + <youpi> dlopen("bug-dlsym1-lib1.so"): bug-dlsym1-lib1.so: cannot open + shared object file: Function not implemented + <youpi> after having changed errno a bit + <youpi> doesn't that look odd ? :) + <youpi> good, I found an issue with the sigstate + <youpi> now running testsuite again, to see whether there are other issues + with it :) + <youpi> s/sigstate/reply_port/ actually + + +## IRC, OFTC, #debian-hurd, 2013-09-23 + + <youpi> yay, errno threadvar conversion success |