Merge remote-tracking branch 'feldtkeller.SCHWINGE/master'

Conflicts:
	hurd/libstore/nbd_store.mdwn
	open_issues/glibc.mdwn
	open_issues/libpthread_CLOCK_MONOTONIC.mdwn
	open_issues/packaging_libpthread.mdwn
	shortcuts.mdwn

1 files changed, 6 insertions, 40 deletions

diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn
index 2d90779e..18f124b4 100644
--- a/open_issues/packaging_libpthread.mdwn
+++ b/open_issues/packaging_libpthread.mdwn
@@ -93,7 +93,6 @@ License|/fdl]]."]]"""]]
       by anybody?
     <youpi> they are half-finished (no __PTHREAD_SPIN_LOCK_INITIALIZER), and
       come in the way when building in glibc
-    <youpi> also, any reason for using ia32 and not i386? glibc uses the latter
     <youpi> pinotree: rid of pthread-stubs yes
     <pinotree> \o/
     <tschwinge> youpi: You mean sysdeps/mach/i386/machine-lock.h?  No idea
@@ -101,7 +100,7 @@ License|/fdl]]."]]"""]]
     <youpi> I'm talking about libpthread
     <youpi> not glibc
     <tschwinge> Oh.
-    <tschwinge> sysdeps/ia32/bits/spin-lock.h:# define
+    <tschwinge> sysdeps/i386/bits/spin-lock.h:# define
       __PTHREAD_SPIN_LOCK_INITIALIZER ((__pthread_spinlock_t) 0)
     <tschwinge> Anyway, no idea about that either.
     <youpi> that one is meant to be used with the spin-lock.h just below
@@ -128,33 +127,6 @@ License|/fdl]]."]]"""]]
       no-add-needed issue
 
 
-## IRC, freenode, #hurd, 2012-04-27
-
-    <pinotree> youpi: wouldn't be the case to rename ia32 subdirs to i386 in
-      libpthread?
-    <pinotree> after all, Makefile hardcodes it, Makefile.am sets the variable
-      for it, and glibc expects i386
-    <youpi> I know, I've asked tschwinge about it
-    <youpi> it's not urging anyway
-    <pinotree> right
-
-
-## IRC, freenode, #hurd, 2012-07-21
-
-    <pinotree> tschwinge: btw, samuel suggested to rename in libpthread ia32 →
-      i386, to better fit with glibc
-    <tschwinge> pinotree: Hmm, that'd somewhat break interopability with
-      Viengoos' use of libpthread.
-    <pinotree> how would it break with viengoos?
-    <tschwinge> I assume it is using the i386 names.  Hmm, no isn't it x86_64
-      only?
-    <tschwinge> I'll check.
-    <pinotree> does it use automake (with the Makefile.am in repo)?
-    <tschwinge> I have no idea what the current branch arrangement is.
-    <pinotree> tschwinge: it looks like ia32 is hardcoded in Makefile and
-      Makefile.am
-
-
 ## IRC, freenode, #hurd, 2012-08-07
 
     <tschwinge> Also, the Savannah hurd/glibc.git one does not/not yet include
@@ -168,15 +140,11 @@ License|/fdl]]."]]"""]]
     <tschwinge> The libpthread in Debian glibc is
       hurd/libpthread.git:b428baaa85c0adca9ef4884c637f289a0ab5e2d6 but with
       25260994c812050a5d7addf125cdc90c911ca5c1 »Store self in __thread variable
-      instead of threadvar« reverted (why?), and the following additional
-      change applied to Makefile:
-    <tschwinge>  ifeq ($(IN_GLIBC),yes)
-    <tschwinge>  $(inst_libdir)/libpthread.so:
-      $(objpfx)libpthread.so$(libpthread.so-version) \
-    <tschwinge>                               $(+force)
-    <tschwinge> -       ln -sf $(slibdir)/libpthread.so$(libpthread.so-version)
-      $@
-    <tschwinge> +       ln -sf libpthread.so$(libpthread.so-version) $@
+      instead of threadvar« reverted (why?), [...]
+
+..., and 549aba4335946c26f2701c2b43be0e6148d27c09 »Fix libpthread.so symlink«
+cherry-picked.
+
     <braunr> tschwinge: is there any plan to merge libpthread.git in glibc.git
       upstream ?
     <tschwinge> braunr, youpi: Has not yet been discussed with Roland, as far
@@ -185,8 +153,6 @@ License|/fdl]]."]]"""]]
     <youpi> libpthread.diff is supposed to be a verbatim copy of the repository
     <youpi> and then there are a couple patches which don't (yet) make sense
       upstream
-    <youpi> the slibdir change, however, is odd
-    <youpi> it must be a leftover
 
 
 # IRC, freenode, #hurd, 2012-11-16