View previous topic :: View next topic |
Author |
Message |
piwacet Guru
Joined: 30 Dec 2004 Posts: 486
|
Posted: Sat Mar 11, 2006 3:23 am Post subject: GLIBC 2.4 now officially in portage |
|
|
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. |
|
Back to top |
|
|
piwacet Guru
Joined: 30 Dec 2004 Posts: 486
|
Posted: Sat Mar 11, 2006 4:35 am Post subject: |
|
|
Well, glibc 2.4 compiled fine with gcc 4.1.0 compiler from portage. Rebuilding rest of toolchain now. |
|
Back to top |
|
|
piwacet Guru
Joined: 30 Dec 2004 Posts: 486
|
Posted: Sat Mar 11, 2006 5:34 am Post subject: |
|
|
O.K. well, made it through toolchain rebuild, doing second toolchain pass now. |
|
Back to top |
|
|
piwacet Guru
Joined: 30 Dec 2004 Posts: 486
|
Posted: Sat Mar 11, 2006 7:21 am Post subject: |
|
|
O.K., toolchain successfully rebuilt, now emerging system. |
|
Back to top |
|
|
Grahammm Tux's lil' helper
Joined: 01 Sep 2004 Posts: 84 Location: Berkshire UK
|
Posted: Sat Mar 11, 2006 9:22 am Post subject: |
|
|
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. |
|
Back to top |
|
|
piwacet Guru
Joined: 30 Dec 2004 Posts: 486
|
Posted: Sat Mar 11, 2006 9:26 am Post subject: |
|
|
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. |
|
Back to top |
|
|
piwacet Guru
Joined: 30 Dec 2004 Posts: 486
|
Posted: Sat Mar 11, 2006 9:42 am Post subject: |
|
|
O.K. bumped coreutils to ~arch and it compiled. Still working on system. |
|
Back to top |
|
|
Helena Veteran
Joined: 02 Apr 2003 Posts: 1114 Location: Den Dolder, The Netherlands
|
Posted: Sat Mar 11, 2006 10:22 am Post subject: |
|
|
what is it again that this version upgrade requires to recompile?
[*]linux-headers
[*]glibc
[*]gcc
[*]binutils
why coreutils? why system? |
|
Back to top |
|
|
younker Apprentice
Joined: 18 Feb 2004 Posts: 280 Location: China
|
Posted: Sat Mar 11, 2006 11:27 am Post subject: |
|
|
emerged successful on X86 with gcc 4.1.0 |
|
Back to top |
|
|
Gentist Apprentice
Joined: 20 Mar 2004 Posts: 247
|
Posted: Sat Mar 11, 2006 11:59 am Post subject: |
|
|
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. |
|
Back to top |
|
|
irondog l33t
Joined: 07 Jul 2003 Posts: 715 Location: Voor mijn TV. Achter mijn pc.
|
Posted: Sat Mar 11, 2006 1:16 pm Post subject: |
|
|
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. _________________ Alle dingen moeten onzin zijn. |
|
Back to top |
|
|
heijs Apprentice
Joined: 12 Jun 2002 Posts: 174 Location: Groningen
|
Posted: Sat Mar 11, 2006 1:51 pm Post subject: |
|
|
I was not able to compile mozilla-firefox with this version glibc. I needed to add the dumpstack patch from Fedora:
Code: |
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. |
|
Back to top |
|
|
Ma3oxuct Guru
Joined: 18 Apr 2003 Posts: 523
|
Posted: Sat Mar 11, 2006 3:01 pm Post subject: |
|
|
Does anyone know what is up with glibc being
Code: | * 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? |
|
Back to top |
|
|
ssmaxss Apprentice
Joined: 28 Jun 2005 Posts: 160 Location: Moscow, Russia.
|
Posted: Sat Mar 11, 2006 3:54 pm Post subject: |
|
|
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? |
|
Back to top |
|
|
chtephan Apprentice
Joined: 03 Feb 2004 Posts: 266 Location: Offenburg, Germany
|
Posted: Sat Mar 11, 2006 3:56 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
Ma3oxuct Guru
Joined: 18 Apr 2003 Posts: 523
|
Posted: Sat Mar 11, 2006 4:04 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
chtephan Apprentice
Joined: 03 Feb 2004 Posts: 266 Location: Offenburg, Germany
|
Posted: Sat Mar 11, 2006 4:14 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
IvanYosifov l33t
Joined: 15 Oct 2004 Posts: 778 Location: Bulgaria
|
Posted: Sat Mar 11, 2006 4:24 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
piwacet Guru
Joined: 30 Dec 2004 Posts: 486
|
Posted: Sun Mar 12, 2006 10:05 am Post subject: |
|
|
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. |
|
Back to top |
|
|
SpanKY Developer
Joined: 18 Apr 2002 Posts: 321 Location: Somerville, MA
|
Posted: Sun Mar 12, 2006 11:32 am Post subject: |
|
|
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 |
|
Back to top |
|
|
rhill Retired Dev
Joined: 22 Oct 2004 Posts: 1629 Location: sk.ca
|
Posted: Sun Mar 12, 2006 6:44 pm Post subject: |
|
|
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. _________________ by design, by neglect
for a fact or just for effect |
|
Back to top |
|
|
madey Tux's lil' helper
Joined: 07 Dec 2005 Posts: 107 Location: Kraków, Poland
|
Posted: Sun Mar 12, 2006 8:42 pm Post subject: |
|
|
Quote: | just set NPTL_KERNEL_VERSION in your make.conf |
Where exactly should I set it?? is it USE? |
|
Back to top |
|
|
younker Apprentice
Joined: 18 Feb 2004 Posts: 280 Location: China
|
Posted: Mon Mar 13, 2006 2:43 am Post subject: |
|
|
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. |
|
Back to top |
|
|
rhill Retired Dev
Joined: 22 Oct 2004 Posts: 1629 Location: sk.ca
|
Posted: Mon Mar 13, 2006 3:03 am Post subject: |
|
|
after a glibc update like this (2.3 -> 2.4) it's a good idea, if not necessary, to emerge -e world. _________________ by design, by neglect
for a fact or just for effect |
|
Back to top |
|
|
ssmaxss Apprentice
Joined: 28 Jun 2005 Posts: 160 Location: Moscow, Russia.
|
Posted: Mon Mar 13, 2006 6:39 am Post subject: |
|
|
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? |
|
Back to top |
|
|
|