Glibc overlay with amd64 performance patches! (obsolete)

Message

nxsty · Post by **nxsty** » Sat Sep 03, 2005 8:29 am

The patches where merged in portage so this thread is obsolete. If you want these patches upgrade to 2.3.6-r3. See the Glibc 2.3.90 snapshot ebuilds thread instead for the 2.3.90 snapshot glibcs!

Creating custom kernels seems popuplar but I decided to be a bit different an created my own glibc ebuild instead.

It started as a way of testing a couple of AMD64 performance patches from suse and mandrake and that's still it's main purpose and feature but it contains changes that benefits other arches as well. There is a bug report about geting those patches included in the official glibc and any feedback about them should also be posted to that bug (#100289). I recomend that you read this whole post before you try it yourself. And if you have any problems post them here but this is completely unsupported and you are using it at your own risk (as always.

). I hope to get some of these changes included in portage.

It's currently based on up to date glibc-2.3.6-r2 and 2.3.5.20050722 ebuilds but it also includes this (more details below):

AMD64 performance enhancements:
* AMD64 optimized libm. (included in portage since 2.3.6-r3)
* AMD64 optimized string routines. (included in portage since 2.3.6-r3)

Generic enhancements
* --enable-kernel bumped to 2.6.9 (2.3.6-r2) or 2.6.11 (2.3.90.2005XXXX). (included in portage since 2.3.6-r3)
* Added back the nomalloccheck USE-flag.
* Updated fedora tarball (2.3.90.2005XXXX only).
* Gcc4 ssp/fortify support controlled by a gcc4ssp USE (2.3.90.2005XXXX only).
* Various fixes to make this build and work. (2.3.90.2005XXXX only).
* Binutils -Bdirect support for faster dynamic loading of libraries. (included in portage since 2.3.6-r3 but disabled by default)
* Binutils -Hashvals support (requires patches binutils) (included in portage since 2.3.6-r3 but disabled by default)

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. Download the overlay from http://snigel.no-ip.com/~nxsty/linux/gl ... ay.tar.bz2 or http://enderandrew.com/nxsty/glibc-overlay.tar.bz2 or http://www.kriga.net/dl/glibc/glibc-overlay.tar.bz2.
2. Untar it in /usr/local/portage/sys-libs
3. Edit make.conf and make sure you have PORTDIR_OVERLAY="/usr/local/portage"
4. Backup your old glibc with quickpkg
(5.) If you are on x86 you should switch to gcc 3.4 first. Run gcc-config and source /etc/profile to make sure it's used.
(6.) If you are using stable you need to unmask =sys-libs/glibc-2.3.6-r2 and sys-libs/timezone-data in /etc/portage/package.keywords. If you want to try the 2.3.90.2005XXXX ebuild you need to unmask it with -*. Binutils 2.16.1-r1 is also needed if you want to try -Bdirect.
7. emerge glibc

No rebuilding or anything is needed and there should be no problems bootstraping with this glibc.

AMD64 performance enhancements:

These comes from an Mandriva SRPM from their latest 2006 release and they took them from Suse but they origin from AMD in the first place. The progress of getting these patches included in portage can be tracked in bug #100289.

*AMD64 optimized libm.
Contains an updated and optimized math library for AMD64 CPUs. Improvements can be seen in Seti@home and the Gimp for example, or anything that uses libm.

*AMD64 optimized string routines.
Increases memory copy performance for AMD64. The improvements can be seen with a small test-program, memcpy.c, which is attatched to the bug (compile it with -O at least).

With the glibc 2.3.5 currently in gentoo:
isidor ~ # ./memcpy 2200 1000 1048576
Memory to memory copy rate = 1291.600098 MBytes / sec. Block size = 1048576.

With glibc 2.3.5 + amd64 optimized string routines:
isidor ~ # ./memcpy 2200 1000 1048576
Memory to memory copy rate = 2389.321777 MBytes / sec. Block size = 1048576.

That's an improvement of over 1000mb/s! Suse 9.3 and 10 also gives about 2300mb/s out of the box.

Generic enhancements

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

Added back the nomalloccheck USE-flag.
The nomalloccheck USE-flag was removed so I added it back. Having malloccheck on comes with a slight overhead and might prevent some buggy apps from running, a problem for binary only apps which you can't do much about. But there is a good reason it's on by default.

* Updated fedora tarball
Updated fedora add-ons from a Fedora SRPM.

* Gcc4 ssp support controlled by a gcc4ssp USE
The gcc4ssp USE-flag turns on SSP and fortify support. Only set this flag if you have a ssp/fortify capable gcc 4 since build will fail otherwise! It's based on chtephan's work. Works perfectly on x86, untested on other arches.

* Enabled building with binutils --as-needed
Enabled building with binutils --as-needed. This change got merged in glibc 2.3.5-r3 and later but the snapshot ebuilds still doesn't have it.

* Various fixes to make this build and work.
Patches from suse glibc-2.3.90-54.src.rpm.

* Binutils -Bdirect support for faster dynamic loading of libraries.
Adds support for the -Bdirect ld-flag to speed up dynamic loading of libraries (OpenOffice, Gnome, KDE for example). This flag breaks glibc so it's filtered out in the ebuild but I'm not sure if it breaks anything else. Why don't you help find out?

Please share your experience with this flag in bug #114008. It requires binutils 2.16.1-r1 to work. As much as possible should be compiled with this flag for best effect. It can coexist with prelink and other LDFLAGS. You should also edit the file /etc/env.d/00basic and add LD_BIND_DIRECT="1". This feature is experimental!

* Binutils -Hashvals support (requires patches binutils)
Adds support for the -Hashvals linker flag (another optimization). To use this you need to create your own overlay for binutils too with the patch from bug #114008. This feature is also experimental!

Questions and answers

Will this break my system?
Probably not, none of the changes are very risky and the amd64 patches are already included in stable releases of mandriva and suse. But you are using it at your own risk so don't blame me if it installs Windows ME or something.

I'm using it myself on several systems including my server which is up 24/7 and I don't have any problems.

dev-libs/apr fail to build against glibc 2.3.90
Run export ac_cv_func_pthread_mutexattr_setrobust_np=no before you emerge it.

I run modular X and are using -Bdirect and X fails to start
Recompile libXfont without -Bdirect to solve the problem.

I can't connect to snigel.no-ip.com!
Try one of the mirrors instead, they are synced once per day so they might be up to 24 h old:
http://enderandrew.com/nxsty/
http://www.kriga.net/dl/glibc/

What arches does it run on?
AMD64 and x86 are the primary arches because that's what I use but it should run on other arches as well. I tried to not break any of the other arches but I haven't tested it.

Are there any known problems?
A older version of the overlay caused some segfaults with nano and azureus. Make sure you run the latest if you have problems, then whine in this thread if it still doesn't work.

This patch also has problems building with a hardened GCC3 AMD64 toolchain. I don't know any good solutions to this except disabling it.

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

Where does the patches come from?
See "AMD64 performance enhancements" above for the AMD64 patches. All patches except 2020 are the work of other people so kudos to them!

Build settings?
Anything should do but I've only tested this with nptl and nptlonly myself. But you might have problems building with the strings patch if you are on hardened or have -fstack-protector(-all) in your CFLAGS.

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. Using this USE-flag on a gcc4 system would normaly make your glibc big and slow but that's fixed in my overlay so now I recomend everyone to set this flag.

If you want to try the -Bdirect patch you need to install binutils 2.16.1-r1 (this exact version). Put -Wl,-Bdirect in your LDFLAGS to use it (after you emerged glibc and binutils with -Bdirect support)

If you want to try the -hashvals patch you need to create your own binutils overlay first. Then put -Wl,-hashvals in yout LDFLAGS. The binutils patch is in bug #114008.

Here is my emerge --info.

Testing

Any performance testing on AMD64 and especially on a nocona system is appreciated. If you see regressions try excluding the string routines patch.

Any testing restults related to the AMD64 patches should also be posted to bug #100289. But you don't need to post your memcpy results in the bug, there is already plenty of those.

Feedback about -Bdirect should go into bug #114008.

Changelog

2006-02-07
*Added a new snapshot. (2.3.90.20060207)
*The -Bdirect and -hashvals flags are supported in this snapshot. (2.3.90.20060207)
*New fedora tarball. (2.3.90.20060207)
*Fixed linuxthreads support. (2.3.90.20060207)

2006-02-02 (3)
*Updated the -Bdirect and -hasvals patches from suse (again

) (2.3.6-r2)

2006-02-02 (2)
*Updated the -Bdirect patch from suse (2.3.6-r2)
*Another new linker optimization from suse: -Wl,hashvals (requires binutils support, not yet in portage) (2.3.6-r2)

2006-02-02
*Synced with portage (2.3.6-r2)

2006-01-21 (2)
*Fixed the segaults problems by removing a broken file, as what's done in recent suse srpms. (2.3.6-r2 and 2.3.90.20060121)

2006-01-21
*New snapshot!
*Added back the -Bdirect patch to the 2.3.90 snapshot, apparently it got lost somwhere. (2.3.90.20060121)
*Removed a patch that clashes with -Bdirect. (2.3.90.20060121)
*Updated the ssp patch from portage. (2.3.6-r2)

2006-01-08 (2)
*Removed some left over digest files.

2006-01-08
*New snapshot, fixes a header problem (2.3.90.2060108)
*Updated the patchset, one of the patches had been partly merged.
*Fixed the ssp patch again.
*Removed the old snapshots.

2006-01-02
*New HEAD snapshot. (2.3.90.2060102)
*Updated fedora tarball. (2.3.90.2060102)
*The 20051211 snapshot is still included since it's known working.
*Synced with portage, now based on 2.3.6-r2 (2.3.6-r2)

2005-12-29 (2)
*Added back the 20051211 snapshot, the new one seems broken.

2005-12-29
*New HEAD snapshot. (2.3.90.20051229)
*Updated patches from suse. (2.3.90.20051229)
*Fixed the ssp patch to apply with the new branch update. (2.3.90.20051229)
*Synced with portage. (2.3.6-r1)

2005-12-13
*Fixed a problem with the ebuild accidently applying a patch that was supposed to be used with gcc4ssp only. (2.3.90.20051211)

2005-12-11 (2)
*Added a depend on dev-util/gperf, apparently it's needed for the build now. (2.3.90.20051211)

2005-12-11
*New HEAD snapshot (2.3.90.20051211)
*Added some linuxthreads updates so it should actually work now. (2.3.90.20051211)

2005-12-06
*Fixed the rejects on the -Bdirect patch and moved it to my patch-tarball (2.3.6-r1 and 2.3.90.20051201).

2005-12-05
*Synced with portage (2.3.6-r1 and 2.3.90.20051201).
*Added filter-flags for -Bdirect from LD- and CFLAGS.
*The -Bdirect patch is inlcuded but not applied since it rejects.

2005-12-01
*New snapshot. (2.3.90.20051201)
*Updated libidn from CVS. (2.3.90.20051201)
*Removed a upstream merged patch. (2.3.90.20051201)

2005-11-23 (2)
*Added a glibc header fix from Tiger683. (2.3.90.20051122)

2005-11-23
*Removed separate ssp patch for gcc4.
*New experimental ebuild: glibc-2.3.90.20051122:
*Based on the glibc-2.3.5.20050722 ebuild.
*Updated snapshot from HEAD.
*Enable kernel bumped to 2.6.11.
*Binutils --as-needed enabled for the build.
*The same AMD64 patches as in 2.3.6.
*Various patches to make this sucker build and work.
*Updated fedora tarball.
*Gcc 4 ssp support based on chtephan's work, controlled by a gcc4ssp USE-flag (Untested currently).

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

Happy gentooing!

orionrobots · Post by **orionrobots** » Sat Sep 03, 2005 9:45 am

A couple of questions for you regarding these.

First would they give any performance increase on Sempron Processors (32 bit AMD's in a 64 bit capable motherboard/slot)? The thought being that some of the allowable optimizations may be down to other fctors tan just the 64 bit architechture, architectural changes which may have also made it into the Sempron - improvements over the XP architecture.

Second - if the patch overlay is placed on a system which does not have such architecture, when you emerge, is its set up intelligent enough not to try to compile in optimizations on a machine it shouldnt (does it query the arch flags?)?

clearly - these may not be known and may require testing.

Regards,
Orion

lightvhawk0 · Post by **lightvhawk0** » Sat Sep 03, 2005 10:03 am

I am currently getting ready to test it...

mbar · Post by **mbar** » Sat Sep 03, 2005 10:12 am

I will test them soon, I'm installing new HDD tonight and gonna reinstall gentoo for AMD64 (can't really copy over my current installation).

playfool · Post by **playfool** » Sat Sep 03, 2005 10:57 am

have these been submitted upstream I wonder, it would be great to get some optimized code in glibc, I assume it has to be ifdef'ed but still.

playfool · Post by **playfool** » Sat Sep 03, 2005 10:58 am

orionrobots wrote:A couple of questions for you regarding these.

First would they give any performance increase on Sempron Processors (32 bit AMD's in a 64 bit capable motherboard/slot)? The thought being that some of the allowable optimizations may be down to other fctors tan just the 64 bit architechture, architectural changes which may have also made it into the Sempron - improvements over the XP architecture.

Second - if the patch overlay is placed on a system which does not have such architecture, when you emerge, is its set up intelligent enough not to try to compile in optimizations on a machine it shouldnt (does it query the arch flags?)?

clearly - these may not be known and may require testing.

Regards,
Orion

I doubt it, I would think the speedups come from using the 64bit registers on the AMD64 to their fullest, so on a 32bit cpu it should explode.

nxsty · Post by **nxsty** » Sat Sep 03, 2005 11:18 am

orionrobots wrote:A couple of questions for you regarding these.

First would they give any performance increase on Sempron Processors (32 bit AMD's in a 64 bit capable motherboard/slot)? The thought being that some of the allowable optimizations may be down to other fctors tan just the 64 bit architechture, architectural changes which may have also made it into the Sempron - improvements over the XP architecture.

Second - if the patch overlay is placed on a system which does not have such architecture, when you emerge, is its set up intelligent enough not to try to compile in optimizations on a machine it shouldnt (does it query the arch flags?)?

clearly - these may not be known and may require testing.

Regards,
Orion

I don't think so. They only modifies the x86_64 parts of glibc which is not built on a x86 system.

devils · Post by **devils** » Sat Sep 03, 2005 11:29 am

I have just installed this patched version of glibc on my AMD64 machine.
memcopy gives me the following result:

Code: Select all

Original glibc in gentoo:
./memcpy 2200 1000 1048576
Memory to memory copy rate = 1134.367310 MBytes / sec. Block size = 1048576.

Recompiled with patches:
./memcpy 2200 1000 1048576
Memory to memory copy rate = 2294.247314 MBytes / sec. Block size = 1048576.

azureus doesn't work, it gives me a segmentation fault:

Code: Select all

/usr/bin/azureus: line 47: 10159 Segmentation fault      java -cp $(java-config -p systray4j,azureus-bin 2>/dev/null) -Djava.library.path="${AZDIR}" org.gudy.azureus2.ui.swt.Main "$1"

Java:

Code: Select all

 java-config -L
[blackdown-jre-1.4.2.02] "Blackdown JRE 1.4.2.02" (/etc/env.d/java/20blackdown-jre-1.4.2.02)
[blackdown-jdk-1.4.2.02] "Blackdown JDK 1.4.2.02" (/etc/env.d/java/20blackdown-jdk-1.4.2.02) *

My emerge -info:

Code: Select all

smaug log # emerge --info
Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.4, glibc-2.3.5-r1, 2.6.13-gentoo-devil x86_64)
=================================================================
System uname: 2.6.13-gentoo-devil x86_64 AMD Athlon(tm) 64 Processor 3800+
Gentoo Base System version 1.12.0_pre7
dev-lang/python:     2.3.5, 2.4.1-r1
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.20
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O3 -march=athlon64 -ffast-math -funroll-loops -funit-at-a-time -fpeel-loops -ftracer -funswitch-loops -fomit-frame-pointer -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb\
/usr/lib64/mozilla/defaults/pref /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=athlon64 -ffast-math -funroll-loops -funit-at-a-time -fpeel-loops -ftracer -funswitch-loops -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://ftp.du.se/pub/os/gentoo/ http://mirror.pudas.net/gentoo/ http://gentoo.eliteitminds.com http://gentoo.mirror.icd.hu/  \
ftp://mir.zyrianes.net/gentoo/"
LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -Wl,--strip-all"
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="X alsa amd64 avi bash-completion bitmap-fonts bzlib cdr crypt cups curl dvd dvdr eds encode esd fam fbcon flac foomaticdb fortran gd gif gnome gpm \
gstreamer gtk gtk2 hal howl imlib imlib2 ipv6 java jpeg lzw lzw-tiff mad mozilla mp3 mpeg ncurses nls nptl nvidia ogg opengl pam pdflib perl png python quicktime \
readline samba sdl snmp spell sqlite ssl sysvipc tcpd tiff truetype-fonts type1-fonts usb userlocales vorbis xine xml xml2 xmms xpm xv zlib userland_GNU \
kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LINGUAS

I have posted at http://bugs.gentoo.org/show_bug.cgi?id=100289 aswell. Anything else that i need to post just tell me and i will post it.

/Jocke W aka Devils

no4b · Post by **no4b** » Sun Sep 04, 2005 1:24 pm

Old glibc:

Code: Select all

./a.out 1800 1000 1048576
Memory to memory copy rate = 1246.030884 MBytes / sec. Block size = 1048576.

New, patched glibc:

Code: Select all

./a.out 1800 1000 1048576
Memory to memory copy rate = 1992.579224 MBytes / sec. Block size = 1048576.

Everything works.

nxsty · Post by **nxsty** » Mon Sep 05, 2005 11:26 am

Thougt I might as well include what i wrote on the bug here:

How about puting the strings patch on hold then and focus on the libm patches?
So we can at least conclude that they are regression free and work on the
strings patch later. I've uploaded a new overlay tarball that no longer applies it:

http://snigel.no-ip.com/~nxsty/linux/gl ... y2.tar.bz2

stonie · Post by **stonie** » Mon Sep 05, 2005 2:41 pm

Hi guys,

applied the patch, too:

old glibc:

Code: Select all

./memcpy 1800 1000 1048576
Memory to memory copy rate = 1406.507690 MBytes / sec. Block size = 1048576.

new glibc:

Code: Select all

./memcpy 1800 1000 1048576
Memory to memory copy rate = 1877.721680 MBytes / sec. Block size = 1048576.

untill now everything works fine. I'll report if somethings break.....

neuron · Post by **neuron** » Mon Sep 05, 2005 3:02 pm

that's quite a nice increase in performance.. can't wait for more stuff to be optimized for 64bit

lightvhawk0 · Post by **lightvhawk0** » Tue Sep 06, 2005 11:50 am

any new results from overlay2??

no4b · Post by **no4b** » Sat Sep 10, 2005 8:45 pm

I've made glibc-2.3.5.20050722 (why? It is considered to build with gcc 4.0.1) ebuild that includes amd64 patches.

If it compiles, I'll post my overlay, maybe someone wants to use gcc4

-edit-

It doesn't compile

Code: Select all

: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a
x86_64-pc-linux-gnu-gcc   -shared -static-libgcc -Wl,-O1  -Wl,-z,defs -Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2  -B/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/csu/  -Wl,--version-script=/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/libm.map -Wl,-soname=libm.so.6 -Wl,-z,relro  -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/dlfcn -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/nss -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/nis -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/rt -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/resolv -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/crypt -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/nptl -Wl,-rpath-link=/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/dlfcn: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/nss: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/nis: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/rt: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/resolv: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/crypt: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/nptl -o /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm.so -T /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/shlib.lds /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/csu/abi-note.o -Wl,--whole-archive /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a -Wl,--no-whole-archive /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/interp.os /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc.so /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc_nonshared.a
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a(e_j0.os): In function `__ieee754_j0':
e_j0.c:(.text+0x4f9): undefined reference to `__cos'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a(e_j0.os): In function `__ieee754_y0':
e_j0.c:(.text+0x7e9): undefined reference to `__cos'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a(e_j1.os): In function `__ieee754_j1':
e_j1.c:(.text+0x4d9): undefined reference to `__cos'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a(e_j1.os): In function `__ieee754_y1':
e_j1.c:(.text+0x6b9): undefined reference to `__cos'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a(e_lgamma_r.os): In function `__ieee754_lgamma_r':
e_lgamma_r.c:(.text+0x284): undefined reference to `__sin'
e_lgamma_r.c:(.text+0x481): undefined reference to `__sin'
e_lgamma_r.c:(.text+0x767): undefined reference to `__cos'
e_lgamma_r.c:(.text+0x78d): undefined reference to `__sin'
e_lgamma_r.c:(.text+0x7b3): undefined reference to `__cos'
collect2: ld returned 1 exit status
make[2]: *** [/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm.so] Error 1
rm /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_finitef.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_signbit.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_copysignf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_isinfl.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_ldexpl.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_isnan.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_finite.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_copysignl.S /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_copysign.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_ldexpf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_isinf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_frexp.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_scalbnf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_finitel.S /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_modf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_isinff.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_isnanf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_signbitl.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_isnanl.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_signbitf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_modff.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_frexpl.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_ldexp.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_scalbnl.S /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_scalbn.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_frexpf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_modfl.c
make[2]: Leaving directory `/var/tmp/portage/glibc-2.3.5.20050722/work/glibc-2.3.5/math'
make[1]: *** [math/others] Error 2
make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.5.20050722/work/glibc-2.3.5'
make: *** [all] Error 2

!!! ERROR: sys-libs/glibc-2.3.5.20050722 failed.
!!! Function toolchain-glibc_src_compile, Line 247, Exitcode 2
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

I don't have time to investigate this problem ;>

Edit: Broken up the rpath= line due to extreme pagelayout breakage. --Maedhros

nxsty · Post by **nxsty** » Sun Sep 11, 2005 8:18 am

You could try using patches from one of suse's snapshot glibcs instead:
ftp://ftp.suse.com/pub/projects/glibc/2.3.90/x86_64/

Also make sure that the libm patch is applied using patch -E, the build fails without it for some reason.

irondog · Post by **irondog** » Sun Sep 11, 2005 9:44 am

What a fscked-up topic! Could the poster in charge (devils) take care of this and edit his post?

no4b · Post by **no4b** » Sun Sep 11, 2005 12:19 pm

nxsty wrote:You could try using patches from one of suse's snapshot glibcs instead:
ftp://ftp.suse.com/pub/projects/glibc/2.3.90/x86_64/

Also make sure that the libm patch is applied using patch -E, the build fails without it for some reason.

I used

Code: Select all

glibc-2.3.3-amd64-s_ceil.diff
glibc-2.3.3-amd64-string.diff
glibc-2.3.libm-ulps.diff
libm-x86-64.diff

from ftp://ftp.suse.com/pub/projects/glibc/2 ... 24.src.rpm and compilled glibc with gcc4.

memcpy (compilled by gcc 4.0.1)says:

Code: Select all

Memory to memory copy rate = 663.564758 MBytes / sec. Block size = 1048576.

That's rather gcc related, because mempcy compilled by gcc 3.4 shows different results.

OddFox · Post by **OddFox** » Sun Sep 11, 2005 3:17 pm

Nice patches and thanks for providing them in such an easy to utilize fashion. No problems to report thus far, I've been using this patched version you're providing since yesterday while performing my installation routine from stage1, and nothing's blown up on me just yet.

I'll be sure to check out all the Java apps once I've had a chance to get them installed, and also just all my other apps in general. So far Fluxbox and the system in general has never felt snappier, but it's all subjective since I don't ever run benchmarks. My memcpy reports the following:

Code: Select all

oddfox ~ # ./memcpy 2200 1000 1048576
Memory to memory copy rate = 2279.598389 MBytes / sec. Block size = 1048576

Gnufsh · Post by **Gnufsh** » Thu Sep 15, 2005 9:45 am

I'm using the latest version without problems here so far. I assume we don't the memcopy improvement without the strings patch (which is ow dis-included)?

OddFox · Post by **OddFox** » Thu Sep 15, 2005 5:30 pm

Well I personally reverted back to the "old" standard glibc just yesterday since I was encountering problems with my copy of GNU Nano not being able to search through documents, it would always segfault. There was one or two other apps that would give me problems that I can't quite recall at the moment, they were minor though and hard to reproduce, the Nano problem was the most prevalent. Since I text-edit using Nano religiously, however, I decided any speed boost from these patches isn't worth having to deal with a b0rked editor.

Surprised nobody else had this problem though, maybe my CFLAGS brought it about in conjunction with the glibc patches.

vipernicus · Post by **vipernicus** » Thu Sep 15, 2005 9:23 pm

no4b wrote:I've made glibc-2.3.5.20050722 (why? It is considered to build with gcc 4.0.1) ebuild that includes amd64 patches.

If it compiles, I'll post my overlay, maybe someone wants to use gcc4

-edit-

It doesn't compile

Code: Select all

: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a
x86_64-pc-linux-gnu-gcc   -shared -static-libgcc -Wl,-O1  -Wl,-z,defs -Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2  -B/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/csu/  -Wl,--version-script=/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/libm.map -Wl,-soname=libm.so.6 -Wl,-z,relro  -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/dlfcn -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/nss -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/nis -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/rt -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/resolv -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/crypt -L/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/nptl -Wl,-rpath-link=/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/dlfcn: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/nss: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/nis: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/rt: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/resolv: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/crypt: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/nptl -o /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm.so -T /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/shlib.lds /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/csu/abi-note.o -Wl,--whole-archive /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a -Wl,--no-whole-archive /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/interp.os /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc.so /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc_nonshared.a
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a(e_j0.os): In function `__ieee754_j0':
e_j0.c:(.text+0x4f9): undefined reference to `__cos'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a(e_j0.os): In function `__ieee754_y0':
e_j0.c:(.text+0x7e9): undefined reference to `__cos'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a(e_j1.os): In function `__ieee754_j1':
e_j1.c:(.text+0x4d9): undefined reference to `__cos'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a(e_j1.os): In function `__ieee754_y1':
e_j1.c:(.text+0x6b9): undefined reference to `__cos'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a(e_lgamma_r.os): In function `__ieee754_lgamma_r':
e_lgamma_r.c:(.text+0x284): undefined reference to `__sin'
e_lgamma_r.c:(.text+0x481): undefined reference to `__sin'
e_lgamma_r.c:(.text+0x767): undefined reference to `__cos'
e_lgamma_r.c:(.text+0x78d): undefined reference to `__sin'
e_lgamma_r.c:(.text+0x7b3): undefined reference to `__cos'
collect2: ld returned 1 exit status
make[2]: *** [/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm.so] Error 1
rm /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_finitef.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_signbit.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_copysignf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_isinfl.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_ldexpl.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_isnan.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_finite.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_copysignl.S /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_copysign.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_ldexpf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_isinf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_frexp.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_scalbnf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_finitel.S /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_modf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_isinff.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_isnanf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_signbitl.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_isnanl.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_signbitf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_modff.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_frexpl.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_ldexp.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_scalbnl.S /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_scalbn.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_frexpf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_modfl.c
make[2]: Leaving directory `/var/tmp/portage/glibc-2.3.5.20050722/work/glibc-2.3.5/math'
make[1]: *** [math/others] Error 2
make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.5.20050722/work/glibc-2.3.5'
make: *** [all] Error 2

!!! ERROR: sys-libs/glibc-2.3.5.20050722 failed.
!!! Function toolchain-glibc_src_compile, Line 247, Exitcode 2
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

I don't have time to investigate this problem ;>

Edit: Broken up the rpath= line due to extreme pagelayout breakage. --Maedhros

It's your LDFLAGs, kill them.

nxsty · Post by **nxsty** » Fri Sep 16, 2005 2:40 pm

Gnufsh wrote:I'm using the latest version without problems here so far. I assume we don't the memcopy improvement without the strings patch (which is ow dis-included)?

I removed it from glibc-overlay2.tar.bz2, glibc-overlay.tar.bz2 still has all the patches.

nxsty · Post by **nxsty** » Fri Sep 16, 2005 2:44 pm

OddFox wrote:Well I personally reverted back to the "old" standard glibc just yesterday since I was encountering problems with my copy of GNU Nano not being able to search through documents, it would always segfault. There was one or two other apps that would give me problems that I can't quite recall at the moment, they were minor though and hard to reproduce, the Nano problem was the most prevalent. Since I text-edit using Nano religiously, however, I decided any speed boost from these patches isn't worth having to deal with a b0rked editor.

Surprised nobody else had this problem though, maybe my CFLAGS brought it about in conjunction with the glibc patches.

The nano problem is well known. I don't know what to do about it except downgrading to nano 1.2.x. Perhaps a recent CVS snapshot will do better?

Anyway it's the strings patch that causes the craches so you could try this overlay instead which only has the libm patches:
http://snigel.no-ip.com/~nxsty/linux/gl ... y2.tar.bz2

Post by **Voyageur** » Fri Sep 16, 2005 6:01 pm

Looks like nano has problems even with "stable" glibc (on ~amd64):
http://forums.gentoo.org/viewtopic-t-381595.html

So it may not be a good indicator of problems with the patches (btw running fine here for 3 weeks now!)

gringo · Post by **gringo** » Tue Sep 20, 2005 1:30 pm

just a a bump and a big thank you to nxsty for his efforts !
Running nice here (including string patch) for one week now, without troubles.

Didnt noticed any problems with nano, azureus or anything.

cheers