* open_issues/packaging_libpthread: One issue fixed.

hurd/libpthread.git, commit af7d78e726cb0d3248c461cfee27fe15121dacd1 »Rename
ia32 sysdep directories to i386.«.

1 files changed, 1 insertions, 29 deletions

diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn
index d22b7be0..be2ca2aa 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