| View previous topic :: View next topic |
| Author |
Message |
Redeeman
l33t
Joined: 25 Sep 2003
Posts: 958
Location: Portugal
|
 Posted: Thu Oct 06, 2005 9:22 pm Post subject: |
 |
|
read the changelog in the dir with the ebuild (in portage)
basically all stuff is non-x86_64.. i see no reason to recompile |
|
| Back to top |
|
 |
satanskin
Guru
Joined: 25 Apr 2005
Posts: 353
|
| Posted: Thu Oct 06, 2005 11:11 pm Post subject: |
|
|
| Eh, already did. Oh well. Hey redeeman, would you mind PMing me with what extra patches you have installed on your kernel? Just curious. |
|
| Back to top |
|
|
Gnufsh
Guru
Joined: 28 Dec 2002
Posts: 400
Location: Portland, OR
|
| Posted: Thu Oct 06, 2005 11:44 pm Post subject: |
|
|
| Redeeman wrote: | read the changelog in the dir with the ebuild (in portage)
basically all stuff is non-x86_64.. i see no reason to recompile |
really?
| Quote: |
06 Oct 2005; Mike Frysinger <vapier@gentoo.org> +glibc-2.3.5-r2.ebuild:
Push out accumulated fixes and fix amd64 multilib error where
C{BUILD,TARGET}_OPT bled across compiles.
|
|
|
| Back to top |
|
|
Redeeman
l33t
Joined: 25 Sep 2003
Posts: 958
Location: Portugal
|
| Posted: Fri Oct 07, 2005 1:22 am Post subject: |
|
|
| Gnufsh wrote: | | Redeeman wrote: | read the changelog in the dir with the ebuild (in portage)
basically all stuff is non-x86_64.. i see no reason to recompile |
really?
| Quote: |
06 Oct 2005; Mike Frysinger <vapier@gentoo.org> +glibc-2.3.5-r2.ebuild:
Push out accumulated fixes and fix amd64 multilib error where
C{BUILD,TARGET}_OPT bled across compiles.
|
|
"basically".. anyway - no reason for me, i dont use multilib |
|
| Back to top |
|
|
Master_Of_Disaster
l33t
Joined: 28 Feb 2003
Posts: 610
Location: 15.05072° East, 48.13747° North (aka Mauer), Austria
|
|
| Back to top |
|
|
nxsty
Veteran
Joined: 23 Jun 2004
Posts: 1556
Location: .se
|
| Posted: Fri Oct 07, 2005 3:19 pm Post subject: |
|
|
Actually I've been thinking about adding those patches. But then my overlay kind of loses its purpose of being a testbed for x86_64 performance patches (If it hasn't already done that when I started adding branch updates and stuff).
But perhaps I'll just rename this thread to "Enhanced glibc overlay with x86_64 performance patches among other things" or something like that and start adding other generic enhancements as well like those gcc4 patches. What do you think? |
|
| Back to top |
|
|
Master_Of_Disaster
l33t
Joined: 28 Feb 2003
Posts: 610
Location: 15.05072° East, 48.13747° North (aka Mauer), Austria
|
| Posted: Fri Oct 07, 2005 4:12 pm Post subject: |
|
|
Well, if this doesn't break compilation with gcc 3.x, why should you not include them? Wasn't the branch update included to compile glibc with gcc 4?
| Code: | EPATCH_OPTS="-E -g0 --no-backup-if-mismatch" \
EPATCH_MULTI_MSG="Applying amd64 optimization patches ..." \
EPATCH_SUFFIX="patch" \
EPATCH_FORCE="yes" \
epatch "${FILESDIR}"/mdk |
BTW: If you apply the patches like this, you can just put them in files/mdk and you don't have to change the ebuild. </wisecracking mode>
_________________
post tenebras lux, post fenestras tux
Registered Linux User Nr. 312509
Adopt an unanswered post today! |
|
| Back to top |
|
|
nxsty
Veteran
Joined: 23 Jun 2004
Posts: 1556
Location: .se
|
| Posted: Fri Oct 07, 2005 7:26 pm Post subject: |
|
|
| Master_Of_Disaster wrote: | | Well, if this doesn't break compilation with gcc 3.x, why should you not include them? Wasn't the branch update included to compile glibc with gcc 4 |
I added it to better match the mandrake SRPM and check what difference it would make in benchmarks. And it did improve results a bit so I decided to keep it. The snapshot is taken from the 2.3 stable branch (unlike the latest snapshots in portage which are from HEAD) so I don't think it has any gcc 4 fixes yet. At least I couldn't find any when searching through changelog.
Thanks for the suggestions btw! |
|
| Back to top |
|
|
Gnufsh
Guru
Joined: 28 Dec 2002
Posts: 400
Location: Portland, OR
|
| Posted: Sat Oct 08, 2005 4:36 pm Post subject: |
|
|
| nxsty wrote: |
Actually I've been thinking about adding those patches. But then my overlay kind of loses its purpose of being a testbed for x86_64 performance patches (If it hasn't already done that when I started adding branch updates and stuff).
But perhaps I'll just rename this thread to "Enhanced glibc overlay with x86_64 performance patches among other things" or something like that and start adding other generic enhancements as well like those gcc4 patches. What do you think? |
I'd prefer not, I mostly just want the x86_64 performance enhancement. I don't want to be testing a bunch of other patches (although I think gcc4 support is a good thing). |
|
| Back to top |
|
|
6D7474
Tux's lil' helper
Joined: 08 Sep 2005
Posts: 135
|
| Posted: Sat Oct 08, 2005 4:49 pm Post subject: |
|
|
This x86_64 enhancement is really nice + everything is working just fine. 
Thx.
BTW i agree with Gnufsh about other patches... |
|
| Back to top |
|
|
satanskin
Guru
Joined: 25 Apr 2005
Posts: 353
|
| Posted: Sat Oct 08, 2005 8:39 pm Post subject: |
|
|
| Gnufsh wrote: | | nxsty wrote: |
Actually I've been thinking about adding those patches. But then my overlay kind of loses its purpose of being a testbed for x86_64 performance patches (If it hasn't already done that when I started adding branch updates and stuff).
But perhaps I'll just rename this thread to "Enhanced glibc overlay with x86_64 performance patches among other things" or something like that and start adding other generic enhancements as well like those gcc4 patches. What do you think? |
I'd prefer not, I mostly just want the x86_64 performance enhancement. I don't want to be testing a bunch of other patches (although I think gcc4 support is a good thing). |
I agree. Please keep this just x86_64 performance patches. Maybe start another thread or add a second overlay to the first post with the others. But please stick to the x86_64 patches. |
|
| Back to top |
|
|
nxsty
Veteran
Joined: 23 Jun 2004
Posts: 1556
Location: .se
|
| Posted: Sun Oct 09, 2005 2:09 pm Post subject: |
|
|
Ok, I'm not going to add a bunch of patches then.  I don't know what patches to add anyway. But I have some other changes coming upp: gcc 4 compatibility (doesn't hurt gcc 3), nomalloccheck USE-flag (makes no difference if you don't se it), and possibly enabling --as-needed for the build. The las one is disabled by default in gentoo's glibc ebuild since a year because it made glibc fail to bootstrap but that seems fixed now. I will also restruture the ebuild a bit to make it easier to maintain. Moving the extra patches + any resynced patches to a separate tarball for example. Then i wont have to repack the gentoo patch tarball everytime it's updated.
Stay tuned. |
|
| Back to top |
|
|
Gnufsh
Guru
Joined: 28 Dec 2002
Posts: 400
Location: Portland, OR
|
| Posted: Sun Oct 09, 2005 3:31 pm Post subject: |
|
|
| nxsty wrote: | Ok, I'm not going to add a bunch of patches then. I don't know what patches to add anyway. But I have some other changes coming upp: gcc 4 compatibility (doesn't hurt gcc 3), nomalloccheck USE-flag (makes no difference if you don't se it), and possibly enabling --as-needed for the build. The las one is disabled by default in gentoo's glibc ebuild since a year because it made glibc fail to bootstrap but that seems fixed now. I will also restruture the ebuild a bit to make it easier to maintain. Moving the extra patches + any resynced patches to a separate tarball for example. Then i wont have to repack the gentoo patch tarball everytime it's updated.
Stay tuned. |
That sounds like a good plan to me (not that it matters what I think). Is there any chance of getting this into portage? |
|
| Back to top |
|
|
nxsty
Veteran
Joined: 23 Jun 2004
Posts: 1556
Location: .se
|
| Posted: Mon Oct 10, 2005 8:12 pm Post subject: |
|
|
The new overlay is now online!
Check the first post and the changelog for more details. The main changes are gcc4 compatibility patches, nomalloccheck USE-flag and building with --as-needed. The AMD64 patches are unchanges. It's boostrap tested on AMD64 and x86 but I haven't tested with gcc4 yet. |
|
| Back to top |
|
|
Gnufsh
Guru
Joined: 28 Dec 2002
Posts: 400
Location: Portland, OR
|
| Posted: Mon Oct 10, 2005 11:16 pm Post subject: |
|
|
| nxsty wrote: | The new overlay is now online!
Check the first post and the changelog for more details. The main changes are gcc4 compatibility patches, nomalloccheck USE-flag and building with --as-needed. The AMD64 patches are unchanges. It's boostrap tested on AMD64 and x86 but I haven't tested with gcc4 yet. |
What does --as-needed do? |
|
| Back to top |
|
|
nxsty
Veteran
Joined: 23 Jun 2004
Posts: 1556
Location: .se
|
| Posted: Tue Oct 11, 2005 8:20 am Post subject: |
|
|
| Gnufsh wrote: | | What does --as-needed do? |
I prevents ld from linking in uneeded libraries. By default ld just links everything on the comandline like if you specify -lX11 for example the binary will link to libX11 even if it doesn't need it. --as-needed prevents it which usually means less memory usage and faster startup times because uneeded libraries isn't loaded. Here is an example using the memcpy.c program:
isidor ~ # gcc -O memcpy.c -o memcpy
isidor ~ # ldd memcpy
libc.so.6 => /lib/libc.so.6 (0x00002aaaaabc4000)
/lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)
isidor ~ # gcc -O -lX11 memcpy.c -o memcpy
isidor ~ # ldd memcpy
libX11.so.6 => /usr/lib/libX11.so.6 (0x0000003530500000)
libc.so.6 => /lib/libc.so.6 (0x00002aaaaabc4000)
libdl.so.2 => /lib/libdl.so.2 (0x00002aaaaae00000)
/lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)
isidor ~ # gcc -O -Wl,-as-needed -lX11 memcpy.c -o memcpy
isidor ~ # ldd memcpy
libc.so.6 => /lib/libc.so.6 (0x00002aaaaabc4000)
/lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000) |
|
| Back to top |
|
|
gralves
Guru
Joined: 20 May 2003
Posts: 389
Location: Sao Paulo, Brazil
|
| Posted: Tue Oct 11, 2005 8:28 am Post subject: |
|
|
| nxsty wrote: | The new overlay is now online!
Check the first post and the changelog for more details. The main changes are gcc4 compatibility patches, nomalloccheck USE-flag and building with --as-needed. The AMD64 patches are unchanges. It's boostrap tested on AMD64 and x86 but I haven't tested with gcc4 yet. |
It compiled and worked w/o a problem here. Thanks! |
|
| Back to top |
|
|
nxsty
Veteran
Joined: 23 Jun 2004
Posts: 1556
Location: .se
|
|
| Back to top |
|
|
gringo
Advocate
Joined: 27 Apr 2003
Posts: 3793
|
| Posted: Wed Oct 12, 2005 10:48 am Post subject: |
|
|
| Quote: | | The new overlay is now online! |
awesome, thanks for this, will try asap and let you know 
Now that this thread isnt getting only glibc specific, maybe you guys also want to have a look to:
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt-current/
Andis kernel patches, some of these are in -mm already.
cheers |
|
| Back to top |
|
|
gralves
Guru
Joined: 20 May 2003
Posts: 389
Location: Sao Paulo, Brazil
|
| Posted: Thu Oct 13, 2005 6:57 pm Post subject: |
|
|
| I also got the azureus crashing bug. |
|
| Back to top |
|
|
Gnufsh
Guru
Joined: 28 Dec 2002
Posts: 400
Location: Portland, OR
|
| Posted: Thu Oct 13, 2005 11:58 pm Post subject: |
|
|
| gralves wrote: | | I also got the azureus crashing bug. |
What version of java are you using? Did you try upgrading to 1.5 (sun-jre-bin) as per the instructions in this thread? That fixed the problem for me. |
|
| Back to top |
|
|
gralves
Guru
Joined: 20 May 2003
Posts: 389
Location: Sao Paulo, Brazil
|
| Posted: Fri Oct 14, 2005 1:00 am Post subject: |
|
|
| Gnufsh wrote: | | gralves wrote: | | I also got the azureus crashing bug. |
What version of java are you using? Did you try upgrading to 1.5 (sun-jre-bin) as per the instructions in this thread? That fixed the problem for me. |
| Code: |
java -version
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_05-b05, mixed mode)
|
|
|
| Back to top |
|
|
nxsty
Veteran
Joined: 23 Jun 2004
Posts: 1556
Location: .se
|
| Posted: Fri Oct 14, 2005 9:19 am Post subject: |
|
|
I have a theory on the crashes. Perhaps gcc 3.4 misscompiles the amd64 string routines code? Both Suse and Mandriva are using gcc 4 and Suse where previously using their own special hammer branch gcc 3.3.
When I did benchmarks (nbench and ubench) with an unpactched glibc vs an amd64 strings patched glibc I got worse results with the later. But then I got better results when I recompiled the patched glibc with gcc 4.
Just a guess..
I'm migrating to gcc 4 now btw. I'm going to upload a new overlay soon with an additional gcc 4 fix for glibc-omitfp. |
|
| Back to top |
|
|
nxsty
Veteran
Joined: 23 Jun 2004
Posts: 1556
Location: .se
|
| Posted: Fri Oct 21, 2005 7:07 pm Post subject: |
|
|
I've updated my overlay again. It now has upstream gcc4 support! Yay. 
Changes since last announcement:
2005-10-21
*New snapshot from the stable branch, fixes bugs #1125, #1384, #721, #1252, #1350, #1251, #1250, #1394. Most gcc4 fixes are now applied upstream.
*Synced ebuild with portage.
*Excluded 5040_all_2.3.4-gcc4.patch and moved a resynced version to my extra patches tarball along wth the other gcc4 fixes.
*Excluded 1520_all_glibc235-execvp-fix.patch 6900_all_ia64-initfini.patch as they are now applied upstream.
*Removed 2011_all_glibc-2.3.5-gcc4_fix_symbols-1.patch, 2012_all_glibc-2.3.5-gcc4_fix_string-1.patch 2013_all_glibc-2.3.5-gcc4_fix_elf-1.patch, 2014_all_glibc-2.3.5-gcc4_fix_iconvdata-1.patch as they are now fixed upstream.
*Changed ebuild to only apply the ssp patches if gcc3 is being used to fix build problems until gcc4 has ssp support.
*extra_patches 0.6
2005-10-12
*Added 2020_all_glibc-2.3.5-gcc4-sanitize-omitfp-optimizations.patch, used when compiling with gcc4 and omitfp (extra_patches 0.5).
*Synced with portage. |
|
| Back to top |
|
|
Cinder6
l33t
Joined: 05 Aug 2004
Posts: 767
Location: California
|
| Posted: Sat Oct 22, 2005 1:37 am Post subject: |
|
|
Love the patch.
_________________
Knowledge is power.
Power corrupts.
Study hard.
Be evil.
Ugly Overload |
|
| Back to top |
|
|
|
Unsupported Software
