Tweaked glibc 2.4 + 2.5 + snapshot ebuilds

Message

nxsty · Post by **nxsty** » Mon Feb 20, 2006 8:09 am

Tweaked glibc 2.4 + 2.5 + snapshot ebuilds

This is the continuing of the "Glibc with amd64 performance patches" thread. The changes from my overlay where included in glibc 2.3.6-r3 and 2.4-r2. The last version of my old overlay is at http://snigel.no-ip.com/~nxsty/linux/gl ... ld.tar.bz2.

It's based on up to date glibc-2.4-r4 and 2.5 ebuilds but it also includes this (more details below):

* --enable-kernel bumped to 2.6.16 (2.4) or 2.6.17 (2.5, 2.5.90.2006XXXX)
* Added back the nomalloccheck USE.
* Build with -DNDEBUG=1 if USE -debug.
* CVS update from HEAD (2.5.90.2006XXXX only).
* Glibc madvise support.
* Binutils --hash-style= support. Requires binutils 2.17.90.0.3 or later.
* Binutils -Bdirect support for faster dynamic loading of libraries. Requires patched binutils. Probably can´t be used with --hash-style.

You can do a diff betwen my ebuild and the ebuild in portage to see what I've changed. Any suggestions are welcome!

How do I use it?

1. Emerge subversion if you don't have it.
2. Pull the overlay by running svn co http://svn.evolution-mission.org/toolch ... ibs/glibc/. If you want you can also pull the whole overlay by running svn co http://svn.evolution-mission.org/toolchain_overlay. That'll get you glibc and a binutils that supports -Bdirect.
2. Put it in /usr/local/toolchain_overlay/sys-libs/
3. Edit make.conf and make sure you have PORTDIR_OVERLAY="/usr/local/toolchain_overlay/"
4. Backup your old glibc with quickpkg
6. Unmask =sys-libs/glibc-2.4* (~arch keyword for 2.5, -* keyword for 2.5.90.2006XXXX).
(7.) If you want to use hashstyle you need to unmask and install binutils 2.17.50.0.3.
(8.) If you´re using stable unmask and install the ~arch linux-headers.
9. emerge glibc

No rebuilding or anything should be needed unless you've enabled hashstyle or -Bdirect for the first time (Don't forget to add appropriate LDFLAGS!).

Enhancements

* --enable-kernel bumped to 2.6.16 or 2.6.17.
This prevents glibc from compiling in compatibility cruft making it leaner and meaner. Of course you need to be running a 2.6.16 or 2.6.17 kernel at least.

* Added back the nomalloccheck USE-flag.
Disable malloccheck. There is a reason why this is on by default. Use with care!

* Glibc madvise support.
Allows glibc to tell the kernel about loaded libraries that are expected to be needed in the near future. Might improve performance somewhat.

* Binutils --hash-style= support
Enables support for --hash-style= in LDFLAGS. It can speed up dynamic loading of libraries quite a bit and obsoletes some of the earlier optimization experiments (-hashvals, -z,dynsort). It probably doesn't work with -Bdirect (yet?).

If you use prelink you need to use at least a 20060712 snapshot.

* Binutils -Bdirect support for faster dynamic loading of libraries.
Adds support for the -Bdirect ld-flag to speed up dynamic loading of libraries. As much as possible should be compiled with this flag for best effect. It can coexist with prelink and other LDFLAGS but probably not --hash-style. You should also edit the file /etc/env.d/00basic and add LD_BIND_DIRECT="1". This feature is experimental!

Bdirect requires a binutils overlay. For more info about about -hashvals, -Bdirect and -z,dynsort check bug #114008.

Questions and answers

Will this break my system?
2.4 and 2.5 are stable relesases so probably not. But there might be some problems with the snapshots. Anyway, what's the fun of never breaking anything?

What arches does it run on?
It should at least run on x86_64 and x86 but probably others too.

Are there any known problems?
Some packages might fail to build against 2.5 if you are on stable, use package.keywords for those!

Is the changelog also included in the overlay?
Yes, check files/changelog.overlay.

Build settings?
Only nptlonly is supported in glibc 2.4 and later.

I recomend that you set the glibc-omitfp USE-flag, it builds all the libs twice, once with extra optimizations and once with the standard settings for debuging purposes. The optimized libraries are used by default.

Here is my emerge --info.

Changelog

2006-10-22
*Synced with portage.
*New snapshot.
*New version of the -Bdirect patch.

2006-10-10
*Synced with portage.
*New snapshot (2.5.90).

2006-10-05
*Removed the hash-style USE from 2.4-r4, the patches are now always applied.
*Added the latest -Bdirect patch to all ebuilds, also always applied.
*Hashvals is no longer supported, use either --hash-style or -Bdirect (but using both will probably break).
*New snapshot.

2006-10-02
*Synced with portage, now using the 2.5 release!
*2.5 now uses the 2.6.17 headers.
*Removed some old files.

2006-09-20
*Fixed -Bdirect support in the 2.4-r4 ebuild.

2006-09-15
*Synced with portage.
*All ebuild now uses the 2.6.16 headers.
*New snapshot (for once nothing needs to be reverted to make it build. Yay!)
*The latest hash-style code from glibc cvs.

2006-08-11
*fixed the build.

2006-08-09
*Added some hash-style fixes from glibc CVS (2.4-rX only)
*Removed old snapshot ebuilds.

2006-08-05
*New snapshot.

2006-08-02
*Moved the hashstyle patches to the patch tarball.

2006-07-21
*Synced with portage.
*New hashstyle patch, extracted from glibc CVS.

2006-07-16
*Synced with portage.
*New snapshot, hash-style patches merged.
*Added the hash-style patches to 2.4 with a hashstyle USE. Thanks to nesl247!

2006-07-01 (2)
*Reverted a commit that borked the build. (2.4.90)

2006-07-01
*Removed gcc 4.0 stuff (fortify USE, santize omitfp)
*New snapshot.
*Synced with portage.

2006-05-16
*New snapshot.
*Reverted a patch to fix build.

2006-05-15
*Synced with portage, based on the -r3 ebuild.
*The ebuild with 2.6.16 headers is now -r4.
*New snapshot.

2006-05-11
*Synced with portage.
*New snapshot.

2006-05-04
*Removed the -r1 ebuild as -r2 is in ~arch.
*Synced the -r2 with portage, it now uses stable 2.6.11 headers.
*Added a -r3 ebuild that is the same as -r2 but uses the 2.6.16 headers.

2006-05-03
*Synced with portage.
*New snapshot.
*Fixed SRC_URI (I think).

2006-04-17
*Synced with portage.
*Added a new snapshot.

2006-04-12
*Synced the 2.4-r2 ebuild with portage.

2006-03-29
*Added a new 2.4-r2 ebuild that uses the 2.6.16 headers (hardmasked currently).
*Added a new snapshot ebuild for those on the bleeding edge.

2006-03-23
*Synced with portage.

2006-03-17
*Synced with portage, based on 2.4-r1.
*Removed some merged patches, including amd64 strings (though it's disabled by default in portage).

2006-03-16
*Added patch from bug #124682, hardened should work now on amd64.

2006-03-15
*Synced with portage.

2006-03-12 (2)
*Updated the libm patch from suse.

2006-03-12
*SSP compile fix.

-- / / snip - see the changelog.overlay for the rest / / --

Happy gentooing!

mbar · Post by **mbar** » Mon Feb 20, 2006 8:26 am

Fortunately, now we have clear situation with your overlay

nxsty · Post by **nxsty** » Mon Feb 20, 2006 8:28 am

Btw, I'm going to make a new snapshot once suse fixes their patches.

PrakashP · Post by **PrakashP** » Mon Feb 20, 2006 8:33 am

@nxsty

Have you checked out and possibly eliminated the performance problem of the snapshots I experienced?

duby2291 · Post by **duby2291** » Mon Feb 20, 2006 8:38 am

* Binutils -Bdirect support for faster dynamic loading of libraries. (also included in portage since 2.3.6-r3 but disabled by default there)

Does this mean that I can use -Bdirect using the glibc in portage?

You say that it is disabled, so how do I enable it?

Martigen · Post by **Martigen** » Mon Feb 20, 2006 8:52 am

nxsty,

Since we need a patched binutils to take advantage of -Bdirect, -hashvals, and -zdynsort, do you think you could make a souped up super-special nxsty binutils overlay?

Mart

duby2291 · Post by **duby2291** » Mon Feb 20, 2006 9:10 am

It doesnt seem like binutils is getting patched with any kind of -bdirect support???

What is the patch called for binutils?

Looking at the output from emerge binutils doesnt show anything that one might relate to bdirect....

I've fount the proper exclusion line from the glibc ebuild, and I've changedit slightly so that it should apply, then I put the modified ebuild into my overlay.... Is that the proper way to do these sorts of things?

CoronaLover · Post by **CoronaLover** » Mon Feb 20, 2006 9:22 am

well the binutills in portage is not working for me, no matter what I compile with it it won't get a .direct section.
I had to create my own binutils ebuild based on the binutils-2.16.91.0.6 ebuild that's in portage and the latest binutils-suse-* patches.

nxsty · Post by **nxsty** » Mon Feb 20, 2006 9:51 am

PrakashP wrote:@nxsty

Have you checked out and possibly eliminated the performance problem of the snapshots I experienced?

The ebuild is almost the same as in my old overlay so I guess the problem remain. But I can't reproduce it here so I'm not sure what's wrong. I hope it gets fixed when I update my overlay next time once suse gets their patches in sync.

nxsty · Post by **nxsty** » Mon Feb 20, 2006 9:53 am

duby2291 wrote:It doesnt seem like binutils is getting patched with any kind of -bdirect support???

What is the patch called for binutils?

Looking at the output from emerge binutils doesnt show anything that one might relate to bdirect....

I've fount the proper exclusion line from the glibc ebuild, and I've changedit slightly so that it should apply, then I put the modified ebuild into my overlay.... Is that the proper way to do these sorts of things?

Only binutils 2.16.1-r1 has the -Bdirect patch but it lacks dynsort and hashvals. It's probably a better idea to do like CoronaLover and create your own binutils overlay with the latest patches. Anyway I uploaded my own binutils overlay. You can get it from:
http://snigel.no-ip.com/~nxsty/linux/bi ... ay.tar.bz2

nxsty · Post by **nxsty** » Mon Feb 20, 2006 9:54 am

duby2291 wrote:
* Binutils -Bdirect support for faster dynamic loading of libraries. (also included in portage since 2.3.6-r3 but disabled by default there)
Does this mean that I can use -Bdirect using the glibc in portage?

You say that it is disabled, so how do I enable it?

Just comment out these lines and run digest on it:

# Do not enable -Bdirect support for now.
GLIBC_PATCH_EXCLUDE="${GLIBC_PATCH_EXCLUDE} 2020_all_2.3.6-hashvals.patch"
GLIBC_PATCH_EXCLUDE="${GLIBC_PATCH_EXCLUDE} 2030_all_2.3.6-bdirect.patch"

rampage7 · Post by **rampage7** » Mon Feb 20, 2006 10:42 am

I've recompiled all my kde packages with -Bdirect flag, using binutils-2.16.1-r1 from portage. I have glibc glibc-2.3.6-r2 from your overlay.

And after recompilation I haven't noticed any speedup in KDE startup. Is it possible to check if certain binary have -Bdirect linker optimization applied?

R. Daneel Olivaw · Post by **R. Daneel Olivaw** » Mon Feb 20, 2006 11:47 am

As was explained in the previous thread you must have the following environment variable:

LD_BIND_DIRECT="1"

It is suggested to put it in /etc/env.d/00basic

duby2291 · Post by **duby2291** » Mon Feb 20, 2006 12:06 pm

Just for curiosity, I dont think it wasever fully explained what hashvals does exactly

What does it do? What kind of impact on the system does it have?

rampage7 · Post by **rampage7** » Mon Feb 20, 2006 12:35 pm

R. Daneel Olivaw wrote:As was explained in the previous thread you must have the following environment variable:

LD_BIND_DIRECT="1"

It is suggested to put it in /etc/env.d/00basic

Is this variable needed during the complilation?

I've set this after kde recompilation.

CoronaLover · Post by **CoronaLover** » Mon Feb 20, 2006 12:39 pm

no, just during runtime.

mbar · Post by **mbar** » Mon Feb 20, 2006 12:41 pm

R. Daneel Olivaw wrote:LD_BIND_DIRECT="1"

It is suggested to put it in /etc/env.d/00basic

I'd suggest that to put it in /etc/env.d/99local, because 00basic gets overwritten.

CoronaLover · Post by **CoronaLover** » Mon Feb 20, 2006 12:48 pm

rampage7 wrote:I've recompiled all my kde packages with -Bdirect flag, using binutils-2.16.1-r1 from portage. I have glibc glibc-2.3.6-r2 from your overlay.

And after recompilation I haven't noticed any speedup in KDE startup. Is it possible to check if certain binary have -Bdirect linker optimization applied?

readelf --direct /path/to/foo.so
should give you some output (all direct symbols in the library actually)

Joffer · Post by **Joffer** » Mon Feb 20, 2006 6:57 pm

nxsty wrote:Just comment out these lines and run digest on it:
# Do not enable -Bdirect support for now.
GLIBC_PATCH_EXCLUDE="${GLIBC_PATCH_EXCLUDE} 2020_all_2.3.6-hashvals.patch"
GLIBC_PATCH_EXCLUDE="${GLIBC_PATCH_EXCLUDE} 2030_all_2.3.6-bdirect.patch"

In the same ebuild file (2.3.6-r3) I find this:

Code: Select all

        # We cannot build glibc with Bdirect support
        filter-flags -Wl,-Bdirect
        filter-ldflags -Bdirect
        filter-ldflags -Wl,-Bdirect

        # Same for hashvals ...
        filter-flags -Wl,-hashvals
        filter-ldflags -hashvals
        filter-ldflags -Wl,-hashvals

Should I just leave it as it is or should this also be commented out?

Tiger683 · Post by **Tiger683** » Mon Feb 20, 2006 7:02 pm

Joffer wrote:
nxsty wrote:Just comment out these lines and run digest on it:
# Do not enable -Bdirect support for now.
GLIBC_PATCH_EXCLUDE="${GLIBC_PATCH_EXCLUDE} 2020_all_2.3.6-hashvals.patch"
GLIBC_PATCH_EXCLUDE="${GLIBC_PATCH_EXCLUDE} 2030_all_2.3.6-bdirect.patch"
In the same ebuild file (2.3.6-r3) I find this:
Code: Select all
        # We cannot build glibc with Bdirect support
        filter-flags -Wl,-Bdirect
        filter-ldflags -Bdirect
        filter-ldflags -Wl,-Bdirect

        # Same for hashvals ...
        filter-flags -Wl,-hashvals
        filter-ldflags -hashvals
        filter-ldflags -Wl,-hashvals
Should I just leave it as it is or should this also be commented out?

Commenting this out would make your new glibc a "Big Fat Hairy Monster (R)"....

So, leave it the way it is.....

Joffer · Post by **Joffer** » Mon Feb 20, 2006 7:23 pm

OK

Going to compile glibc now with my fixed glibc-2.3.6-r3 ebuild in /usr/local/portage...

Edit:

Hmmm...

running 'ebuild glibc-2.3.6-r3.ebuild digest' after I commented out the two lines gives me a lot of:

Code: Select all

livecd glibc # ebuild glibc-2.3.6-r3.ebuild digest
>>> Downloading http://mirror.gent2oo.no/distfiles/glibc-2.3.6-patches-1.8.tar.bz2
--20:29:09--  http://mirror.gent2oo.no/distfiles/glibc-2.3.6-patches-1.8.tar.bz2
           => `/usr/portage/distfiles/glibc-2.3.6-patches-1.8.tar.bz2'
Resolving mirror.gent2oo.no... 212.125.220.50
Connecting to mirror.gent2oo.no[212.125.220.50]:80... connected.
HTTP request sent, awaiting response... 404 Not Found
20:29:09 ERROR 404: Not Found.

No digest file available and download failed.

>>> Downloading http://ftp.du.se/pub/os/gentoo/distfiles/glibc-2.3.6-patches-1.8.tar.bz2
--20:29:09--  http://ftp.du.se/pub/os/gentoo/distfiles/glibc-2.3.6-patches-1.8.tar.bz2
           => `/usr/portage/distfiles/glibc-2.3.6-patches-1.8.tar.bz2'
Resolving ftp.du.se... 130.243.32.22
Connecting to ftp.du.se[130.243.32.22]:80... connected.
HTTP request sent, awaiting response... 404 Not Found
20:29:09 ERROR 404: Not Found.

No digest file available and download failed.

It just keeps giving me "Not Found" for all the mirrors it tries... Any suggestions?

nesl247 · Post by **nesl247** » Mon Feb 20, 2006 7:56 pm

Change the 1.8 to 1.7.. I think I read this somewhere else on the board..

Joffer · Post by **Joffer** » Mon Feb 20, 2006 8:45 pm

nesl247 wrote:Change the 1.8 to 1.7.. I think I read this somewhere else on the board..

Looks like it works like a charm.. I guess there is a bug in the latest ebuild then....

Joffer · Post by **Joffer** » Tue Feb 21, 2006 1:39 am

Joffer wrote:
nesl247 wrote:Change the 1.8 to 1.7.. I think I read this somewhere else on the board..
Looks like it works like a charm.. I guess there is a bug in the latest ebuild then....

Hmm.. looks like it borkes out when I try to compile glibc..:

Code: Select all

livecd local # emerge -av glibc binutils gcc libstdc++-v3 libtool portage

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild     U ] sys-libs/glibc-2.3.6-r3 [2.3.5] USE="nls nptl* nptlonly* pic* userlocales -build -erandom -glibc-compat20% -glibc-omitfp% -hardened -linuxthreads-tls% -profile%" 0 kB [1]
[ebuild   R   ] sys-devel/binutils-2.16.1  USE="multislot nls -multitarget -test" 0 kB
[ebuild  N    ] dev-libs/gmp-4.1.4-r3  USE="-doc -nocxx" 1,641 kB
[ebuild  N    ] dev-libs/mpfr-2.2.0_p8  738 kB
[ebuild  NS   ] sys-devel/gcc-4.0.2-r3  USE="fortran gtk multislot nls -bootstrap -boundschecking -build -gcj -ip28 -mudflap -nocxx -nopie -objc -objc-gc -vanilla" 31,139 kB
[ebuild  N    ] virtual/libstdc++-3.3  0 kB
[ebuild   R   ] sys-libs/libstdc++-v3-3.3.4  USE="nls nptl% -build%" 22,784 kB
[ebuild  N    ] perl-core/Test-Simple-0.62  USE="-minimal" 68 kB
[ebuild  N    ] virtual/perl-Test-Simple-0.62  0 kB
[ebuild  N    ] dev-perl/Locale-gettext-1.05  USE="-minimal" 7 kB
[ebuild  N    ] sys-apps/help2man-1.33.1  USE="nls" 73 kB
[ebuild     U ] sys-devel/libtool-1.5.22 [1.5.18-r1] 2,853 kB
[ebuild   R   ] sys-apps/portage-2.1_pre4-r1  USE="-build -doc" 0 kB

Total size of downloads: 59,306 kB
Portage overlays:
 [1] /usr/local/portage

Do you want me to merge these packages? [Yes/No] y
>>> emerge (1 of 13) sys-libs/glibc-2.3.6-r3 to /
>>> checksums files   ;-) glibc-2.3.6-r3.ebuild
>>> checksums files   ;-) files/digest-glibc-2.3.6-r3
>>> checksums src_uri ;-) glibc-2.3.6.tar.bz2
>>> checksums src_uri ;-) glibc-linuxthreads-2.3.6.tar.bz2
>>> checksums src_uri ;-) glibc-libidn-2.3.6.tar.bz2
>>> checksums src_uri ;-) glibc-2.3.6-patches-1.7.tar.bz2
>>> checksums src_uri ;-) glibc-manpages-2.3.6-1.tar.bz2
>>> checksums src_uri ;-) glibc-infopages-2.3.6.tar.bz2
>>> checksums src_uri ;-) glibc-fedora-20041219T2331.tar.bz2
>>> Unpacking source...

 * Checking gcc for __thread support ... no

 * Could not find a gcc that supports the __thread directive!
 * please update to gcc-3.2.2-r1 or later, and try again.

!!! ERROR: sys-libs/glibc-2.3.6-r3 failed.
Call stack:
  ebuild.sh, line 1894:   Called dyn_unpack
  ebuild.sh, line 694:   Called src_unpack
  glibc-2.3.6-r3.ebuild, line 1174:   Called toolchain-glibc_src_unpack
  glibc-2.3.6-r3.ebuild, line 191:   Called check_nptl_support

!!! No __thread support in gcc!
!!! If you need support, post the topmost build error, and the call stack if relevant.

The glibc-2.3.6-r3.ebuild is the portage provided one, copied to /usr/local/portage/sys-libs/glibc and edited so that I can have bdirect and hashvals patches:

Code: Select all

        # Do not enable -Bdirect support for now.
#       GLIBC_PATCH_EXCLUDE="${GLIBC_PATCH_EXCLUDE} 2020_all_2.3.6-hashvals.patch"
#       GLIBC_PATCH_EXCLUDE="${GLIBC_PATCH_EXCLUDE} 2030_all_2.3.6-bdirect.patch"

I tried without the patches also, but get the same error..

I have switched to the 2006.0 profile. Would that create any trouble?
/etc/portage/package.keywords

Code: Select all

~sys-libs/glibc-2.3.6 ~amd64
~sys-devel/gcc-4.0.2 -*
~sys-apps/portage-2.1_pre4 ~amd64
~dev-python/pycrypto-2.0.1 ~amd64
~sys-libs/timezone-data-2006a ~amd64

~app-admin/eselect-1.0 ~amd64
~dev-util/ccache-2.4 ~amd64
~app-portage/ufed-0.40 ~amd64

media-video/nvidia-kernel ~amd64
media-video/nvidia-glx ~amd64

/etc/portage/package.use

Code: Select all

sys-libs/glibc nptl nptlonly pic userlocales
sys-devel/libperl ithreads
dev-lang/perl ithreads
sys-devel/binutils multislot
sys-devel/gcc multislot

/etc/portage/package.unmask

Code: Select all

=sys-devel/gcc-4.0*

emerge info

Code: Select all

Portage 2.1_pre4-r1 (default-linux/x86/2006.0, gcc-3.4.3, glibc-2.3.5-r0, 2.6.12-gentoo-r6 x86_64)
=================================================================
System uname: 2.6.12-gentoo-r6 x86_64 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.6.13
ccache version 2.4 [enabled]
dev-lang/python:     2.3.5-r2
sys-apps/sandbox:    1.2.11
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5
sys-devel/binutils:  2.15.92.0.2-r10, 2.16.1
sys-devel/libtool:   1.5.18-r1
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64 x86"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=k8 -pipe -O2"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=k8 -pipe -O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks fixpackages sandbox sfperms strict"
GENTOO_MIRRORS="http://mirror.gentoo.no/ http://ftp.du.se/pub/os/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="x86 alsa apache2 apm arts avi berkdb bitmap-fonts crypt cups eds emboss encode esd foomaticdb fortran gdbm gif gpm gstreamer gtk imlib ipv6 jpeg libg++ libwww mad mikmod motif mp3 mpeg ncurses nls nptl nptlonly ogg opengl oss pam pdflib perl png python quicktime readline sdl spell ssl tcpd truetype truetype-fonts type1-fonts udev vorbis xml xmms xv zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux userland_GNU video_cards_nvidia video_cards_vesa"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL, LDFLAGS, LINGUAS

I'm still installing/compiling using a chroot under the livecd.. should I perhaps just emerge a kernel and get the system up running by itself?

nesl247 · Post by **nesl247** » Tue Feb 21, 2006 1:45 am

Your version of gcc probably doesn't support __thread. (According to the error). You need to update gcc first.