Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Glibc overlay with amd64 performance patches! (obsolete)
View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3 ... 21, 22, 23  Next  
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
nxsty
Veteran
Veteran


Joined: 23 Jun 2004
Posts: 1556
Location: .se

PostPosted: Sat Sep 03, 2005 8:29 am    Post subject: Glibc overlay with amd64 performance patches! (obsolete) Reply with quote

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. :D 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/glibc-overlay.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? :wink: 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! :)


Last edited by nxsty on Mon Feb 20, 2006 8:21 am; edited 102 times in total
Back to top
View user's profile Send private message
orionrobots
Apprentice
Apprentice


Joined: 07 Oct 2003
Posts: 289
Location: London, Uk

PostPosted: Sat Sep 03, 2005 9:45 am    Post subject: Reply with quote

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
_________________
Danny Staple, curator of http://orionrobots.co.uk
Adopt an unanswered post initiative https://forums.gentoo.org/search.php?search_id=unanswered
Back to top
View user's profile Send private message
lightvhawk0
Guru
Guru


Joined: 07 Nov 2003
Posts: 388

PostPosted: Sat Sep 03, 2005 10:03 am    Post subject: Reply with quote

I am currently getting ready to test it... :D
_________________
If God has made us in his image, we have returned him the favor. - Voltaire
Back to top
View user's profile Send private message
mbar
Veteran
Veteran


Joined: 19 Jan 2005
Posts: 1990
Location: Poland

PostPosted: Sat Sep 03, 2005 10:12 am    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
playfool
l33t
l33t


Joined: 01 Jun 2004
Posts: 688
Location: Århus, Denmark

PostPosted: Sat Sep 03, 2005 10:57 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
playfool
l33t
l33t


Joined: 01 Jun 2004
Posts: 688
Location: Århus, Denmark

PostPosted: Sat Sep 03, 2005 10:58 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
nxsty
Veteran
Veteran


Joined: 23 Jun 2004
Posts: 1556
Location: .se

PostPosted: Sat Sep 03, 2005 11:18 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
devils
n00b
n00b


Joined: 19 Nov 2004
Posts: 17

PostPosted: Sat Sep 03, 2005 11:29 am    Post subject: Reply with quote

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

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:

/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:

 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:

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 https://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


Last edited by devils on Sun Sep 11, 2005 6:45 pm; edited 2 times in total
Back to top
View user's profile Send private message
no4b
Bodhisattva
Bodhisattva


Joined: 18 Jan 2004
Posts: 774
Location: Tarnów, Poland

PostPosted: Sun Sep 04, 2005 1:24 pm    Post subject: Reply with quote

Old glibc:

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


New, patched glibc:

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


Everything works.
Back to top
View user's profile Send private message
nxsty
Veteran
Veteran


Joined: 23 Jun 2004
Posts: 1556
Location: .se

PostPosted: Mon Sep 05, 2005 11:26 am    Post subject: Reply with quote

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/glibc-overlay2.tar.bz2
Back to top
View user's profile Send private message
stonie
Tux's lil' helper
Tux's lil' helper


Joined: 03 Jun 2003
Posts: 87
Location: S'Minga, Halleluja

PostPosted: Mon Sep 05, 2005 2:41 pm    Post subject: Reply with quote

Hi guys,

applied the patch, too:

old glibc:
Code:

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


new glibc:
Code:

./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.....
_________________
How could I know what I think before I realized what I said???

http://valid.x86-secret.com/show_oc?id=63327
Back to top
View user's profile Send private message
neuron
Advocate
Advocate


Joined: 28 May 2002
Posts: 2371

PostPosted: Mon Sep 05, 2005 3:02 pm    Post subject: Reply with quote

that's quite a nice increase in performance.. can't wait for more stuff to be optimized for 64bit :)
Back to top
View user's profile Send private message
lightvhawk0
Guru
Guru


Joined: 07 Nov 2003
Posts: 388

PostPosted: Tue Sep 06, 2005 11:50 am    Post subject: Reply with quote

any new results from overlay2??
_________________
If God has made us in his image, we have returned him the favor. - Voltaire
Back to top
View user's profile Send private message
no4b
Bodhisattva
Bodhisattva


Joined: 18 Jan 2004
Posts: 774
Location: Tarnów, Poland

PostPosted: Sat Sep 10, 2005 8:45 pm    Post subject: Reply with quote

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:
: /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
_________________
GTK2/GNOME - The weakest link!
Back to top
View user's profile Send private message
nxsty
Veteran
Veteran


Joined: 23 Jun 2004
Posts: 1556
Location: .se

PostPosted: Sun Sep 11, 2005 8:18 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
irondog
l33t
l33t


Joined: 07 Jul 2003
Posts: 715
Location: Voor mijn TV. Achter mijn pc.

PostPosted: Sun Sep 11, 2005 9:44 am    Post subject: Reply with quote

What a fscked-up topic! Could the poster in charge (devils) take care of this and edit his post?
_________________
Alle dingen moeten onzin zijn.
Back to top
View user's profile Send private message
no4b
Bodhisattva
Bodhisattva


Joined: 18 Jan 2004
Posts: 774
Location: Tarnów, Poland

PostPosted: Sun Sep 11, 2005 12:19 pm    Post subject: Reply with quote

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:
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.3.90/x86_64/20050724/glibc-2.3.90-14.0.20050724.src.rpm and compilled glibc with gcc4.

memcpy (compilled by gcc 4.0.1)says:

Code:
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.
Back to top
View user's profile Send private message
OddFox
Apprentice
Apprentice


Joined: 28 Nov 2002
Posts: 270
Location: Spokane, WA

PostPosted: Sun Sep 11, 2005 3:17 pm    Post subject: Reply with quote

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:
oddfox ~ # ./memcpy 2200 1000 1048576
Memory to memory copy rate = 2279.598389 MBytes / sec. Block size = 1048576

_________________
Now the rainy season reminds me of Maria
The way she danced, the color of her hair
Now I'm locked inside a stall at the cantina
Eating the bananas and the cocaine off the mirror
Looking for a ticket to take me away from here
Back to top
View user's profile Send private message
Gnufsh
Guru
Guru


Joined: 28 Dec 2002
Posts: 400
Location: Portland, OR

PostPosted: Thu Sep 15, 2005 9:45 am    Post subject: Reply with quote

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)?
Back to top
View user's profile Send private message
OddFox
Apprentice
Apprentice


Joined: 28 Nov 2002
Posts: 270
Location: Spokane, WA

PostPosted: Thu Sep 15, 2005 5:30 pm    Post subject: Reply with quote

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.
_________________
Now the rainy season reminds me of Maria
The way she danced, the color of her hair
Now I'm locked inside a stall at the cantina
Eating the bananas and the cocaine off the mirror
Looking for a ticket to take me away from here
Back to top
View user's profile Send private message
vipernicus
Veteran
Veteran


Joined: 17 Jan 2005
Posts: 1462
Location: Your College IT Dept.

PostPosted: Thu Sep 15, 2005 9:23 pm    Post subject: Reply with quote

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:
: /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.
_________________
Viper-Sources Maintainer || nesl247 Projects || vipernicus.org blog
Back to top
View user's profile Send private message
nxsty
Veteran
Veteran


Joined: 23 Jun 2004
Posts: 1556
Location: .se

PostPosted: Fri Sep 16, 2005 2:40 pm    Post subject: Reply with quote

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.


Last edited by nxsty on Fri Sep 16, 2005 2:45 pm; edited 1 time in total
Back to top
View user's profile Send private message
nxsty
Veteran
Veteran


Joined: 23 Jun 2004
Posts: 1556
Location: .se

PostPosted: Fri Sep 16, 2005 2:44 pm    Post subject: Reply with quote

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/glibc-overlay2.tar.bz2
Back to top
View user's profile Send private message
Voyageur
Developer
Developer


Joined: 06 Mar 2005
Posts: 342
Location: Paris, France

PostPosted: Fri Sep 16, 2005 6:01 pm    Post subject: Reply with quote

Looks like nano has problems even with "stable" glibc (on ~amd64):
https://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!)
_________________
Routinely breaking NX, GNUstep, net-ftp, miscellaneous (llvm, filezilla, rdesktop, chromium, ...) packages
Back to top
View user's profile Send private message
gringo
Advocate
Advocate


Joined: 27 Apr 2003
Posts: 3793

PostPosted: Tue Sep 20, 2005 1:30 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page 1, 2, 3 ... 21, 22, 23  Next
Page 1 of 23

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum