Tweaked glibc 2.4 + 2.5 + snapshot ebuilds

Message

nxsty · Post by **nxsty** » Thu Mar 30, 2006 7:30 am

mbar wrote:KDE 3.5.2 compiled fine with -O2, so I have to ask, why is -Os not filtered?

Because gcc 4.1 is a unsupported, hardmasked compiler?

FireBurn · Post by **FireBurn** » Thu Mar 30, 2006 8:42 am

nxsty wrote:
mbar wrote:KDE 3.5.2 compiled fine with -O2, so I have to ask, why is -Os not filtered?
Because gcc 4.1 is a unsupported, hardmasked compiler?

Why isn't there problems thought when KDE is run with root?

Mike

seren · Post by **seren** » Fri Mar 31, 2006 5:51 pm

create a new user, and try to see if you can log in under that login, your /home/$user/.kde stiff may be B0rked

6D7474 · Post by **6D7474** » Sat Apr 01, 2006 10:01 pm

i've recompiled world with new kernel headers and everything seems to be ok. No problems with any compilations or unexpected crashes...

SpanKY · Post by **SpanKY** » Sat Apr 01, 2006 10:30 pm

pussi wrote:-z now slows down application startup, but increases owerall performance since all shared libraries load at application startup.

true that it does slow down startup, but not quite for that reason ... -z now forces all *symbols* to be *resolved* at startup (before user main() is invoked) ... default behavior is lazy bindings where symbols are resolved only as needed

ldso will always map in all shared libs in the dependency tree into the memory space regardless of the bind state

avoid · Post by **avoid** » Mon Apr 03, 2006 3:41 am

Hi. I'm not sure what exactly is wrong with the glibc-2.4-r2 ebuild, but it fails configuring saying that linux-headers >= 2.6.16 are needed for this version. Even if I have the latest -* version of the headers, the ebuild fails. right after the tarball gets unpacked, it checks for the linux-headers version. linux-headers-2.6.16 are installed but not detected by this ebuild. I'm sorry but I can't paste the error message. I can also confirm that the glibc-2.4-r1 works fine here.
* Checking gcc for __thread support ... yes
* Checking kernel version (>=2.6.11) ... yes
* Checking linux-headers version (>=2.6.11) ... yes
Basically, instead of saying yes at Checking linux-headers version.. it fails with a big no. the configuration process stops there. emerge exists and that's all. Maybe someone can give me some hint?!

rhill · Post by **rhill** » Mon Apr 03, 2006 4:23 am

there's a report that the 2.6.16 headers break building kcontrol. can anyone confirm this or is it PEBKAC?

http://forums.gentoo.org/viewtopic-t-448273.html

maquiz · Post by **maquiz** » Mon Apr 03, 2006 4:30 am

Hi. I'm not sure what exactly is wrong with the glibc-2.4-r2 ebuild, but it fails configuring saying that linux-headers >= 2.6.16 are needed for this version. .... I can also confirm that the glibc-2.4-r1 works fine here.
* Checking gcc for __thread support ... yes
* Checking kernel version (>=2.6.11) ... yes
* Checking linux-headers version (>=2.6.11) ... yes
Basically, instead of saying yes at Checking linux-headers version.. it fails with a big no. the configuration process stops there. emerge exists and that's all. Maybe someone can give me some hint?!

When you compile your glibc, do you also run on a 2.6.16 kernel? the ebuild checks for both 2.6.16 linux-headers and a running 2.6.16 kernel. If you don't, compile a 2.6.16 kernel or use the latest SLAX-livecd, as it uses a 2.6.16 kernel.

nxsty · Post by **nxsty** » Mon Apr 03, 2006 7:08 am

avoid wrote:Hi. I'm not sure what exactly is wrong with the glibc-2.4-r2 ebuild, but it fails configuring saying that linux-headers >= 2.6.16 are needed for this version. Even if I have the latest -* version of the headers, the ebuild fails. right after the tarball gets unpacked, it checks for the linux-headers version. linux-headers-2.6.16 are installed but not detected by this ebuild. I'm sorry but I can't paste the error message. I can also confirm that the glibc-2.4-r1 works fine here.
* Checking gcc for __thread support ... yes
* Checking kernel version (>=2.6.11) ... yes
* Checking linux-headers version (>=2.6.11) ... yes
Basically, instead of saying yes at Checking linux-headers version.. it fails with a big no. the configuration process stops there. emerge exists and that's all. Maybe someone can give me some hint?!

In my overlay the the -r2 ebuild is the same as the -r1 but uses the 2.6.16 headers instead. I haven't added the -r2 ebuild from portage yet.

Joffer · Post by **Joffer** » Wed Apr 05, 2006 11:50 am

Is there any good reason why I should switch from 2.6.11 to 2.6.16 headers?

taylorpendley · Post by **taylorpendley** » Wed Apr 05, 2006 12:05 pm

i cant compile gpm with 2.6.16 headers unless i use the headers with glibc-2.4-r2 so dont use them unless you do it with glibc-2.4-r2 not glibc-2.4-r1...
also im not sure if it was the headers or glibc-2.4-r2 but when i was compiling ebuilds i contstantly got OUT OF BOUNDS messages....there were so many i could barely see the actual compilation of the packages....it might have something to do with me being x86_64 but im just going to keep using 2.6.11 and glibc-2.4-r1 unless theres so me great benefit to using them

Joffer · Post by **Joffer** » Wed Apr 05, 2006 3:38 pm

Ok, so there is no performance to gain and such by going with 2.6.16 headers?

immudium · Post by **immudium** » Wed Apr 05, 2006 3:44 pm

taylorpendley wrote:also im not sure if it was the headers or glibc-2.4-r2 but when i was compiling ebuilds i contstantly got OUT OF BOUNDS messages....there were so many i could barely see the actual compilation of the packages....it might have something to do with me being x86_64 but im just going to keep using 2.6.11 and glibc-2.4-r1 unless theres so me great benefit to using them

That's strange, I completely recompiled my toolchain and world with nxsty's glibc-2.4-r2 and kernel headers 2.6.16 on an amd64 box and didn't have a single issue outside of the known build failures I already expected from using gcc 4.1 and the new kernel (i.e. splashutils). I do have 2GB of memory in the box. Could that be the difference? How much ram and swap do you have on yours?

immudium · Post by **immudium** » Wed Apr 05, 2006 4:22 pm

Joffer wrote:Ok, so there is no performance to gain and such by going with 2.6.16 headers?

Eesh, I am probably the least qualified to answer this, but in absence of any other discussion on the topic, I'll give it a shot. Maybe it will motivate a reproving jab at my stupidity from someone with better qualifications.

Anyway, my understanding of the purpose of the linux headers is to expose functionality contained within the kernel to the outside world like someone writing a new driver not contained in the kernel tree. Thus I wouldn't expect newer headers to change performance in any way because they don't really do anything other than open a window to the outside world of the inner workings of the linux kernel. The only way performance would improve would be for a programmer to specifically code to a newly exposed function that took advantage of some sort of performance improvement within the kernel itself, but since the API is so new, it's doubtful that anything has been written yet to take advantage yet. At least nothing that has trickled down to us lowly users from the developers on high. Glibc 2.4 may take advantage of such new functionality but I don't know for sure. I doubt it would be all that significant if it did.

nxsty · Post by **nxsty** » Wed Apr 05, 2006 9:00 pm

Joffer wrote:Ok, so there is no performance to gain and such by going with 2.6.16 headers?

New headers allows glibc to take advantage of new features but it might also improve performance since you don't have to compile in compatibility for older kernels, though I don't except it to do much.

From install.texi:

@item --enable-kernel=@var{version}
This option is currently only useful on GNU/Linux systems. The
@var{version} parameter should have the form X.Y.Z and describes the
smallest version of the Linux kernel the generated library is expected
to support. The higher the @var{version} number is, the less
compatibility code is added, and the faster the code gets.

mrcs · Post by **mrcs** » Thu Apr 06, 2006 4:13 pm

Hi,

I'm having a problem that I don't really know the cause of. I'm using nxtys glibc-2.4-r2, linux-headers-2.6.16 and beyond-sources (stable) and I can't compile mplayer with USE="rtc". All I get is this:

Code: Select all

In file included from mplayer.c:180:
libmpdemux/demuxer.h:107: error: field "get_current" declared as a function
make: *** [mplayer.o] Fel 1

So I was just wondering if anyone else using a similar setup is having the same problem? Same problem for this guy.

weedy · Post by **weedy** » Fri Apr 07, 2006 9:10 am

Code: Select all

a - elf/unwind-dw2-fde-glibc.os
a - elf/framestate.os
a - elf/unwind-pe.os
: /var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/libc_pic.a
gcc -Wl,-O1 -Wl,--enable-new-dtags -Wl,-zdynsort -Wl,--as-needed -Wl,--sort-common -s  -nostdlib -nostartfiles -r -o /var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/elf/librtld.map.o '-Wl,-(' /var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/elf/dl-allobjs.os /var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/elf/librtld.mapT
/var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/libc_pic.a(init-first.os):(.data+0x0): multiple definition of `__libc_multiple_libcs'
/var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/elf/dl-allobjs.os:(.bss+0x74): first defined here
/var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/libc_pic.a(_itoa.os): In function `_itoa':_itoa.c:(.text+0x100): multiple definition of `_itoa'
/var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/elf/dl-allobjs.os: first defined here
/usr/lib/gcc/i586-pc-linux-gnu/3.4.6/../../../../i586-pc-linux-gnu/bin/ld: Warning: size of symbol `_itoa' changed from 116 in /var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/elf/dl-allobjs.os to 494 in /var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/libc_pic.a(_itoa.os)
collect2: ld returned 1 exit status
make[2]: *** [/var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/elf/librtld.map] Error 1
make[2]: Leaving directory `/var/tmp/portage/glibc-2.4.20060329/work/glibc-2.4/elf'
make[1]: *** [elf/subdir_lib] Error 2
make[1]: Leaving directory `/var/tmp/portage/glibc-2.4.20060329/work/glibc-2.4'
make: *** [all] Error 2

!!! ERROR: sys-libs/glibc-2.4.20060329 failed.
Call stack:
  ebuild.sh, line 1526:   Called dyn_compile
  ebuild.sh, line 923:   Called src_compile
  glibc-2.4.20060329.ebuild, line 1297:   Called toolchain-glibc_src_compile
  glibc-2.4.20060329.ebuild, line 283:   Called die

!!! make for default failed
!!! If you need support, post the topmost build error, and the call stack if relevant.

Ideas?

StringCheesian · Post by **StringCheesian** » Fri Apr 07, 2006 9:44 am

weedy wrote:

Code: Select all

a - elf/unwind-dw2-fde-glibc.os
a - elf/framestate.os
a - elf/unwind-pe.os
: /var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/libc_pic.a
gcc -Wl,-O1 -Wl,--enable-new-dtags -Wl,-zdynsort -Wl,--as-needed -Wl,--sort-common -s  -nostdlib -nostartfiles -r -o /var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/elf/librtld.map.o '-Wl,-(' /var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/elf/dl-allobjs.os /var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/elf/librtld.mapT
/var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/libc_pic.a(init-first.os):(.data+0x0): multiple definition of `__libc_multiple_libcs'
/var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/elf/dl-allobjs.os:(.bss+0x74): first defined here
/var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/libc_pic.a(_itoa.os): In function `_itoa':_itoa.c:(.text+0x100): multiple definition of `_itoa'
/var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/elf/dl-allobjs.os: first defined here
/usr/lib/gcc/i586-pc-linux-gnu/3.4.6/../../../../i586-pc-linux-gnu/bin/ld: Warning: size of symbol `_itoa' changed from 116 in /var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/elf/dl-allobjs.os to 494 in /var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/libc_pic.a(_itoa.os)
collect2: ld returned 1 exit status
make[2]: *** [/var/tmp/portage/glibc-2.4.20060329/work/build-default-i586-pc-linux-gnu-nptl/elf/librtld.map] Error 1
make[2]: Leaving directory `/var/tmp/portage/glibc-2.4.20060329/work/glibc-2.4/elf'
make[1]: *** [elf/subdir_lib] Error 2
make[1]: Leaving directory `/var/tmp/portage/glibc-2.4.20060329/work/glibc-2.4'
make: *** [all] Error 2

!!! ERROR: sys-libs/glibc-2.4.20060329 failed.
Call stack:
  ebuild.sh, line 1526:   Called dyn_compile
  ebuild.sh, line 923:   Called src_compile
  glibc-2.4.20060329.ebuild, line 1297:   Called toolchain-glibc_src_compile
  glibc-2.4.20060329.ebuild, line 283:   Called die

!!! make for default failed
!!! If you need support, post the topmost build error, and the call stack if relevant.

Ideas?

Same problem in German: http://forums.gentoo.org/viewtopic-t-447239.html
Second post there links to this bug: http://bugs.gentoo.org/show_bug.cgi?id=94325

weedy · Post by **weedy** » Fri Apr 07, 2006 11:00 am

i don't have the file for the work around.
*pokes nxsty in the face* fix it >.>

rhill · Post by **rhill** » Fri Apr 07, 2006 8:08 pm

weedy wrote:i don't have the file for the work around.
*pokes nxsty in the face* fix it >.>

hey, fix it yourself or don't use an experimental toolchain. you're expected to know what you're doing, not rudely demanding someone fix it for you.

vipernicus · Post by **vipernicus** » Fri Apr 07, 2006 8:28 pm

n0rbi666 wrote:
mbar wrote:Anybody from here has "kompiled" new kde 3.5.2? It crashes on me all the time, I used -Os optimization (and usual ftracer fweb fomit, nothing insane) and -O1 -z,now -s LDFLAGS. gcc 4.1 glibc 2.4, all I get after starting kde is bare desktop with 3 icons, when I close xorg I can see a screenful of "application 'blahblah' crashes" in console.
gcc4.1 does'nt like -Os - especialy with c++ apps (I've had this problem using gcc-4.1-beta and -Os, and with firefox, gcc4.1 and -Os)
Try to change it to -O2 and reemerge KDE - I'm using glibc from this overlay, gcc-4.1.0 from portage, insane cflags (with -O2) - and everything is working ok )

I emerged my system with no problems with these flags, so -Os could not have been the culprit:

Code: Select all

CFLAGS="-march=athlon-xp"
CFLAGS="${CFLAGS} -Os"
CFLAGS="${CFLAGS} -pipe"
CFLAGS="${CFLAGS} -fomit-frame-pointer"
CFLAGS="${CFLAGS} -fno-ident"
CFLAGS="${CFLAGS} -funit-at-a-time"
CFLAGS="${CFLAGS} -freorder-blocks-and-partition"
CXXFLAGS="${CFLAGS} -fno-enforce-eh-specs"
CXXFLAGS="${CXXFLAGS}  -fvisibility-inlines-hidden"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,-Bdirect -Wl,-hashvals -Wl,-zdynsort"

weedy · Post by **weedy** » Fri Apr 07, 2006 11:15 pm

dirtyepic wrote:
weedy wrote:i don't have the file for the work around.
*pokes nxsty in the face* fix it >.>
hey, fix it yourself or don't use an experimental toolchain. you're expected to know what you're doing, not rudely demanding someone fix it for you.

I have been using experimental packages and ebuilds for a while i know they don't always work but in this case i don't have the know how to fix it myself, even the work around in the bug fails :/

immudium · Post by **immudium** » Sat Apr 08, 2006 4:43 am

weedy wrote:
dirtyepic wrote:
weedy wrote:i don't have the file for the work around.
*pokes nxsty in the face* fix it >.>
hey, fix it yourself or don't use an experimental toolchain. you're expected to know what you're doing, not rudely demanding someone fix it for you.
I have been using experimental packages and ebuilds for a while i know they don't always work but in this case i don't have the know how to fix it myself, even the work around in the bug fails :/

Geez weedy, what the hell makes you so special that you think you can demand special attention to your problems? If you can't fix it yourself, then use a different overlay or start doing some reading and use your brain for a change. Maybe you'll gain some common sense on how to deal with people along the way. I mean why else would you be messing around with an experimental, non-released, NON-SUPPORTED snapshot overlay if not to learn? It's certainly not going to make your machine magically faster, win you fame and fortune nor make you 133t. So why act so childish?

weedy · Post by **weedy** » Sat Apr 08, 2006 6:51 am

immudium wrote:
weedy wrote:
dirtyepic wrote:
weedy wrote:i don't have the file for the work around.
*pokes nxsty in the face* fix it >.>
hey, fix it yourself or don't use an experimental toolchain. you're expected to know what you're doing, not rudely demanding someone fix it for you.
I have been using experimental packages and ebuilds for a while i know they don't always work but in this case i don't have the know how to fix it myself, even the work around in the bug fails :/
Geez weedy, what the hell makes you so special that you think you can demand special attention to your problems? If you can't fix it yourself, then use a different overlay or start doing some reading and use your brain for a change. Maybe you'll gain some common sense on how to deal with people along the way. I mean why else would you be messing around with an experimental, non-released, NON-SUPPORTED snapshot overlay if not to learn? It's certainly not going to make your machine magically faster, win you fame and fortune nor make you 133t. So why act so childish?

Ok a: it was ment in gest b: i am in fact a child so i am well within my rights to act my age c: this is turning in to a flame war so can we please drop it.

weedy · Post by **weedy** » Sat Apr 08, 2006 1:22 pm

cvs ebuild works perfect on my normal gcc installs, it's only hardened that curls up and dies. Oh hardened why must you make me work for your love

PS. it's building kde now no errors so far.

Edit: x11-libs/qt-3.3.6 exploded not sure what the problem is, might be -Wl,--as-needed. searching the forums etc

Tweaked glibc 2.4 + 2.5 + snapshot ebuilds

mplayer with rtc