GLIBC 2.4 now officially in portage

Message

piwacet · Post by **piwacet** » Sat Mar 11, 2006 3:23 am

Just emerge --sync'd and 2.4 showed up as ~arch on my amd64.

Guess I'll have a go at it.

Wish me luck.

piwacet · Post by **piwacet** » Sat Mar 11, 2006 4:35 am

Well, glibc 2.4 compiled fine with gcc 4.1.0 compiler from portage. Rebuilding rest of toolchain now.

piwacet · Post by **piwacet** » Sat Mar 11, 2006 5:34 am

O.K. well, made it through toolchain rebuild, doing second toolchain pass now.

piwacet · Post by **piwacet** » Sat Mar 11, 2006 7:21 am

O.K., toolchain successfully rebuilt, now emerging system.

Grahammm · Post by **Grahammm** » Sat Mar 11, 2006 9:22 am

I was rather surprised to see glibc 2.4 come straight into ~arch, I would have expected it to have gone into package mask for a while first. I have not yet started to upgrade, I am still running gcc 3.4.5 but the gnu announcement for glibc 2.4 states that gcc 4.1 is prefered but this is package masked and I am not sure I want to try upgrading 2 major components at once.

piwacet · Post by **piwacet** » Sat Mar 11, 2006 9:26 am

Yeah, it's probably worth doing it one at a time.

FYI, still working on emerge -e system. died on coreutils, I'm continuing on with system to see what else happens.

piwacet · Post by **piwacet** » Sat Mar 11, 2006 9:42 am

O.K. bumped coreutils to ~arch and it compiled. Still working on system.

Helena · Post by **Helena** » Sat Mar 11, 2006 10:22 am

what is it again that this version upgrade requires to recompile?
[*]linux-headers
[*]glibc
[*]gcc
[*]binutils

why coreutils? why system?

younker · Post by **younker** » Sat Mar 11, 2006 11:27 am

emerged successful on X86 with gcc 4.1.0

Gentist · Post by **Gentist** » Sat Mar 11, 2006 11:59 am

Since glibc more or less requires gcc 4.1.0, is it "safe" to unmask it, seeing as it is currently hardmasked? I've masked glibc for now since it refuses to compile without it.

irondog · Post by **irondog** » Sat Mar 11, 2006 1:16 pm

Helena wrote:what is it again that this version upgrade requires to recompile?
why coreutils? why system?

Because some people believe that after a toolchain update a system can be in a broken state in which everything is still working. If a system would really break one wouldn't be able to use portage.

Still I recommand re-emerging world --emptytree on a very big major update on any part of the toolchain. To repeat this several times sounds like paranoia bullshit to me.

Besides that glibc is has a stable ABI/API. One should be able to upgrade glibc without any problems.

heijs · Post by **heijs** » Sat Mar 11, 2006 1:51 pm

I was not able to compile mozilla-firefox with this version glibc. I needed to add the dumpstack patch from Fedora:

Code: Select all

Index: xpcom/base/nsTraceRefcntImpl.cpp
===================================================================
RCS file: /cvs/mozilla/xpcom/base/nsTraceRefcntImpl.cpp,v
retrieving revision 1.98
diff -p -u -1 -2 -r1.98 nsTraceRefcntImpl.cpp
--- xpcom/base/nsTraceRefcntImpl.cpp    3 Feb 2006 19:35:14 -0000       1.98
+++ xpcom/base/nsTraceRefcntImpl.cpp    6 Feb 2006 20:30:53 -0000
@@ -41,37 +41,24 @@
 #include "nsISupports.h"
 #include "nsVoidArray.h"
 #include "prprf.h"
 #include "prlog.h"
 #include "plstr.h"
 #include <stdlib.h>
 #include "nsCOMPtr.h"
 #include "nsCRT.h"
 #include <math.h>

 #if defined(_WIN32)
 #include <windows.h>
-#elif defined(linux) && defined(__GLIBC__) && (defined(__i386) || defined(PPC))-#include <setjmp.h>
-
-//
-// On glibc 2.1, the Dl_info api defined in <dlfcn.h> is only exposed
-// if __USE_GNU is defined.  I suppose its some kind of standards
-// adherence thing.
-//
-#if (__GLIBC_MINOR__ >= 1) && !defined(__USE_GNU)
-#define __USE_GNU
-#endif
-
-#include <dlfcn.h>
 #endif

 #ifdef HAVE_LIBDL
 #include <dlfcn.h>
 #endif

 ////////////////////////////////////////////////////////////////////////////////

 NS_COM void
 NS_MeanAndStdDev(double n, double sumOfValues, double sumOfSquaredValues,
                  double *meanResult, double *stdDevResult)
 {
@@ -451,25 +438,25 @@ static PRIntn PR_CALLBACK DumpSerialNumb
                             record->COMPtrCount);
 #else
   fprintf((FILE*) aClosure, "%d (%d references)\n",
                             record->serialNumber,
                             record->refCount);
 #endif
   return HT_ENUMERATE_NEXT;
 }


 #endif /* NS_BUILD_REFCNT_LOGGING */

-nsresult
+NS_COM nsresult
 nsTraceRefcntImpl::DumpStatistics(StatisticsType type, FILE* out)
 {
   nsresult rv = NS_OK;
 #ifdef NS_BUILD_REFCNT_LOGGING
   if (gBloatLog == nsnull || gBloatView == nsnull) {
     return NS_ERROR_FAILURE;
   }
   if (out == nsnull) {
     out = gBloatLog;
   }

   LOCK_TRACELOG();
@@ -528,25 +515,25 @@ nsTraceRefcntImpl::DumpStatistics(Statis
   if (gSerialNumbers) {
     fprintf(out, "\n\nSerial Numbers of Leaked Objects:\n");
     PL_HashTableEnumerateEntries(gSerialNumbers, DumpSerialNumbers, out);
   }

 done:
   gLogging = wasLogging;
   UNLOCK_TRACELOG();
 #endif
   return rv;
 }

-void
+NS_COM void
 nsTraceRefcntImpl::ResetStatistics()
 {
 #ifdef NS_BUILD_REFCNT_LOGGING
   LOCK_TRACELOG();
   if (gBloatView) {
     PL_HashTableDestroy(gBloatView);
     gBloatView = nsnull;
   }
   UNLOCK_TRACELOG();
 #endif
 }

@@ -812,43 +799,43 @@ static void InitTraceLog(void)

   if (gBloatLog || gRefcntsLog || gAllocLog || gLeakyLog || gCOMPtrLog) {
     gLogging = PR_TRUE;
   }

   gTraceLock = PR_NewLock();
 }

 #endif

 #if defined(_WIN32) && defined(_M_IX86) && !defined(WINCE) // WIN32 x86 stack walking code
 #include "nsStackFrameWin.h"
-void
+NS_COM void
 nsTraceRefcntImpl::WalkTheStack(FILE* aStream)
 {
   DumpStackToFile(aStream);
 }

 // WIN32 x86 stack walking code
 // i386 or PPC Linux stackwalking code or Solaris
-#elif (defined(linux) && defined(__GLIBC__) && (defined(__i386) || defined(PPC))) || (defined(__sun) && (defined(__sparc) || defined(sparc) || defined(__i386)
|| defined(i386)))
+#elif (defined(linux) && defined(__GNUC__) && (defined(__i386) || defined(PPC))) || (defined(__sun) && (defined(__sparc) || defined(sparc) || defined(__i386) || defined(i386)))
 #include "nsStackFrameUnix.h"
-void
+NS_COM void
 nsTraceRefcntImpl::WalkTheStack(FILE* aStream)
 {
   DumpStackToFile(aStream);
 }

 #else // unsupported platform.

-void
+NS_COM void
 nsTraceRefcntImpl::WalkTheStack(FILE* aStream)
 {
        fprintf(aStream, "write me, dammit!\n");
 }

 #endif

 //----------------------------------------------------------------------

 // This thing is exported by libstdc++
 // Yes, this is a gcc only hack
 #if defined(MOZ_DEMANGLE_SYMBOLS)
Index: xpcom/base/nsStackFrameUnix.cpp
===================================================================
RCS file: /cvs/mozilla/xpcom/base/nsStackFrameUnix.cpp,v
retrieving revision 1.14
diff -p -u -1 -2 -r1.14 nsStackFrameUnix.cpp
--- xpcom/base/nsStackFrameUnix.cpp     3 Feb 2006 19:35:14 -0000       1.14
+++ xpcom/base/nsStackFrameUnix.cpp     6 Feb 2006 20:28:06 -0000
@@ -74,43 +74,33 @@ void DemangleSymbol(const char * aSymbol
     /* See demangle.h in the gcc source for the voodoo */
     char * demangled = abi::__cxa_demangle(aSymbol,0,0,0);

     if (demangled)
     {
         strncpy(aBuffer,demangled,aBufLen);
         free(demangled);
     }
 #endif // MOZ_DEMANGLE_SYMBOLS
 }


-#if defined(linux) && defined(__GLIBC__) && (defined(__i386) || defined(PPC)) // i386 or PPC Linux stackwalking code
+#if defined(linux) && defined(__GNUC__) && (defined(__i386) || defined(PPC)) // i386 or PPC Linux stackwalking code

-#include <setjmp.h>
-//

 void DumpStackToFile(FILE* aStream)
 {
-  jmp_buf jb;
-  setjmp(jb);
-
   // Stack walking code courtesy Kipp's "leaky".

-  // Get the frame pointer out of the jmp_buf
-  void **bp = (void**)
-#if defined(__i386)
-    (jb[0].__jmpbuf[JB_BP]);
-#elif defined(PPC)
-    (jb[0].__jmpbuf[JB_GPR1]);
-#endif
+  // Get the frame pointer
+  void **bp = (void**) __builtin_frame_address(0);

   int skip = 2;
   for ( ; (void**)*bp > bp; bp = (void**)*bp) {
     void *pc = *(bp+1);
     if (--skip <= 0) {
       Dl_info info;
       int ok = dladdr(pc, &info);
       if (!ok) {
         fprintf(aStream, "UNKNOWN %p\n", pc);
         continue;
       }

I hope this will help others with the same problem.

Ma3oxuct · Post by **Ma3oxuct** » Sat Mar 11, 2006 3:01 pm

Does anyone know what is up with glibc being

Code: Select all

 * glibc-2.4 is nptl-only!

Personally, I have packages that can't live with nptl (i.e. need the linuxthreads fall-back), so I am masking this.

Are linuxthreads going to be phased out entirely at some point in time?

ssmaxss · Post by **ssmaxss** » Sat Mar 11, 2006 3:54 pm

Glibc 2.4 is in portage but it still uses --enable-kernel 2.6.9 but I whant --enable-kernel 2.6.11 . So still use overlay. Maybe file the bug that glibc should detect what linux-headers I have?

chtephan · Post by **chtephan** » Sat Mar 11, 2006 3:56 pm

Out of curiosity: Which programs don't work with NPTL?

The developer cleary stated from the beginning that linuxthreads was a hack and nobody should rely on it being a permanent solution. Hey, fortunately NPTL was designed backwards-compatible and programes compiled against linuxthreads work with it out-of-the-box. And usually it does. Except for programs which did fiddle with linuxthread internals or relied on linuxthreads behaviour whereas the documentation stated that they shouldn't have done that.

Linuxthreads should die. So should developers who wrote software that doesn't work without it.

This is once more proof that closed-source software sucks and hinders software evolution.

Ma3oxuct · Post by **Ma3oxuct** » Sat Mar 11, 2006 4:04 pm

chtephan wrote:Out of curiosity: Which programs don't work with NPTL?

dvd::rip.

I am recompiling my non-production system with glibc-2.4 to see if this is still the case.

chtephan · Post by **chtephan** » Sat Mar 11, 2006 4:14 pm

Are you sure? How come? This is a maintained (or at least open-source, so someone could fix it) program and if I see correctly it uses perl so it shouldn't fiddle around with threading itself. I can't really believe that it might have problems with NPTL.

: I personally have completely dropped linuxthreads two years ago and never looked back.

IvanYosifov · Post by **IvanYosifov** » Sat Mar 11, 2006 4:24 pm

Ma3oxuct wrote: Are linuxthreads going to be phased out entirely at some point in time?

I think that as far as non-legacy-and-binary-only software is concerned they are already phased out.

piwacet · Post by **piwacet** » Sun Mar 12, 2006 10:05 am

O.K. successfully rebuilt all of world with glibc-2.4. I had to bump coreutils and busybox to ~arch to get them to compile, that was the only complication.

SpanKY · Post by **SpanKY** » Sun Mar 12, 2006 11:32 am

ssmaxss wrote:Glibc 2.4 is in portage but it still uses --enable-kernel 2.6.9 but I whant --enable-kernel 2.6.11 . So still use overlay. Maybe file the bug that glibc should detect what linux-headers I have?

that's a really bad idea

just set NPTL_KERNEL_VERSION in your make.conf

rhill · Post by **rhill** » Sun Mar 12, 2006 6:44 pm

Ma3oxuct wrote:
chtephan wrote:Out of curiosity: Which programs don't work with NPTL?
dvd::rip.

I am recompiling my non-production system with glibc-2.4 to see if this is still the case.

it's not, and hasn't been for a while.

madey · Post by **madey** » Sun Mar 12, 2006 8:42 pm

just set NPTL_KERNEL_VERSION in your make.conf

Where exactly should I set it?? is it USE?

younker · Post by **younker** » Mon Mar 13, 2006 2:43 am

Seems the new glibc breaks the header file for ruby, so when you try to build koffice which has ruby dependency, it will fail on ruby includes, just re-merge ruby with the new glibc can solve this problem.

And another problem is it seems it breaks some jpeg related application, for example, gimp, gimp can open some jpeg files, but cann't open jpeg files shoted by Minolta Alpha 5D, just re-merge jpeg and gimp, solved this problem.

rhill · Post by **rhill** » Mon Mar 13, 2006 3:03 am

after a glibc update like this (2.3 -> 2.4) it's a good idea, if not necessary, to emerge -e world.

ssmaxss · Post by **ssmaxss** » Mon Mar 13, 2006 6:39 am

In overlay I have flag gcc4ssp to enable ssp support with gcc 4. In portage it is enabled by default? There is no such flag in portage. Adding NPTL_KERNEL_VERSION="2.6.11" to make.conf helped to fix problem about kernel headers. What about SSP?