Glibc overlay with amd64 performance patches! (obsolete)

Message

fca · Post by **fca** » Tue Jan 17, 2006 3:58 pm

urcindalo wrote:Well, I just rebuilt all my system over the weekend using your glibc-2.3.6-r2 overlay. I use AMD64.

nano 1.3.9 crashes almost everytime I search. Not only that, but it also wiped out my whole package.keywords file an hour ago when saving, forcing me to rewrite it from scratch

So, I'm thinking of three solutions:

1) Going back to portage's 2.3.5-r2 AMD64 stable
2) Using your overlay changing whatever is necessary to avoid more crashes.
3) Using portage's own 2.3.6-r2.

What is my best option? If it is 2), what should I modify?
And by the way, what are the differences between your 2.3.6-rs ebuild and portage's?

Thanks in advance.

I had the same problem, it is due to the strings patches. Remove the # before the line which reads

Code: Select all

EXTRA_PATCH_EXCLUDE="${EXTRA_PATCH_EXCLUDE} 1020_all_glibc-2.3.3-amd64-string-20050813.patch"

and recompile glibc. That should fix the problem.

urcindalo · Post by **urcindalo** » Tue Jan 17, 2006 4:59 pm

OK. Doing it right now. I'l let you know the result.

maquiz · Post by **maquiz** » Thu Jan 19, 2006 4:51 pm

I am trying to build a server system with SSP enabled, based on the gcc- and glibc-overlay, starting
from a gcc-4.0.2 enabled Rockhopper stage1/3 installation. I use slightly updated gcc-4.0.2.20051117-r1,
glibc-2.3.90.20060112 and binutils-2.16.1-r1 ebuilds with the gcc4ssp USE-flag enabled.

I rebuild the toolchain via emerge glibc binutils gcc, but creates with a circular dependy during compilation:
As I compile glibc with gcc4ssp enabled, it informs me it misses a SSP-enabled gcc, and if I want to
compile gcc it informs me it misses a SSP-enabled glibc. A chicken-or-the-egg problem thus.

Thus how can I create a gcc4ssp enabled toolchain?? Disabling gcc4ssp does not create a SSP-enabled glibc.

The gcc-error is:

* Applying stub patch for htb ... [ ok ]
* Applying gcc-4.0-ssp.patch ... [ ok ]

!!! ERROR: sys-devel/gcc-4.0.2.20051117-r2 failed.
!!! Function libc_has_ssp, Line 108, Exitcode 1
!!! external libssp not supported
!!! If you need support, post the topmost build error, NOT this status message.

nxsty · Post by **nxsty** » Thu Jan 19, 2006 7:58 pm

You have to compile glibc 2.3.90 first without the gcc4ssp USE-flag and a gcc4 without SSP, like 4.0.2-r3 in portage. Then upgrade to the SSP-enabled gcc and use it to rebuild the toolchain with the gcc4ssp use-flag enabled. That's what I did when I migrated my server.

Sorry for the lack of updates btw. I've been bussy. The 2.3.90 ebuild apparently misses the -Bdirect patch. I must have lost it when I upgraded the tarball but I'll add it back.

nxsty · Post by **nxsty** » Sat Jan 21, 2006 10:34 am

I updated the overlay with a new snapshot. The -Bdirect patch is now included in 2.3.90 again.

nxsty · Post by **nxsty** » Sat Jan 21, 2006 12:15 pm

nxsty wrote:I updated the overlay with a new snapshot. The -Bdirect patch is now included in 2.3.90 again.

I've updated it again. This should fix the segfault problems with nano and azureus I hope! Please test!

PrakashP · Post by **PrakashP** » Sat Jan 21, 2006 12:16 pm

nxsty wrote:
I've updated it again. This should fix the segfault problems with nano and azureus I hope! Please test!

Just curious: What did you change that this would work w/o taking string pathc out?

nxsty · Post by **nxsty** » Sat Jan 21, 2006 12:19 pm

PrakashP wrote:Just curious: What did you change that this would work w/o taking string pathc out?

Recent suse glibc srpms does:

# strncmp is broken, let's delete it for now this way
rm sysdeps/x86_64/strncmp.S

So I added it to the ebuild and it seems to have fixed it.

PrakashP · Post by **PrakashP** » Sat Jan 21, 2006 3:13 pm

Won't install for me (on amd64):

Code: Select all

make -j4 -j1 -C stdio-common subdir_install
make[2]: Entering directory `/var/tmp/portage/glibc-2.3.90.20060121/work/glibc-2.3.6/stdio-common'
/bin/install -c -m 644 stdio_ext.h /var/tmp/portage/glibc-2.3.90.20060121/image//usr/include/stdio_ext.h
/bin/install -c -m 644 printf.h /var/tmp/portage/glibc-2.3.90.20060121/image//usr/include/printf.h
make[2]: *** No rule to make target `/var/tmp/portage/glibc-2.3.90.20060121/image//usr/include/bits/printf-ldbl.h', needed by `install-headers-nosubdir'.  Stop.
make[2]: Leaving directory `/var/tmp/portage/glibc-2.3.90.20060121/work/glibc-2.3.6/stdio-common'
make[1]: *** [stdio-common/subdir_install] Error 2
make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.90.20060121/work/glibc-2.3.6'
make: *** [install] Error 2

I grepped and got:

glibc-2.3.6/ChangeLog: * stdio-common/bits/printf-ldbl.h: New file.

but the file is missing. Is your snapshot incomplete?

Code: Select all

[ebuild     U ] sys-libs/glibc-2.3.90.20060121 [2.3.90.20051211] USE="glibc-omitfp linuxthreads-tls nls nptl nptlonly pic userlocales -build -debug -erandom -gcc4ssp -glibc-compat20 -hardened -nomalloccheck -profile" 0 kB [1]

fca · Post by **fca** » Sat Jan 21, 2006 4:09 pm

nxsty wrote:
PrakashP wrote:Just curious: What did you change that this would work w/o taking string pathc out?
Recent suse glibc srpms does:
# strncmp is broken, let's delete it for now this way
rm sysdeps/x86_64/strncmp.S
So I added it to the ebuild and it seems to have fixed it.

nano still gives a bus error for me, so no go.
But, I looked through the ebuild, and there is no mention of strncmp.S or something like that. I'll try adding the rm sysdeps/x86_64/strncmp.S line to the ebuild to see if that fixes the problem.

NiLuJe · Post by **NiLuJe** » Sat Jan 21, 2006 4:15 pm

Same as PrakashP on x86

Code: Select all

make[2]: Entering directory `/var/tmp/portage/glibc-2.3.90.20060121/work/glibc-2.3.6/stdio-common'
/bin/install -c -m 644 stdio_ext.h /var/tmp/portage/glibc-2.3.90.20060121/image//usr/include/stdio_ext.h
/bin/install -c -m 644 printf.h /var/tmp/portage/glibc-2.3.90.20060121/image//usr/include/printf.h
make[2]: *** No rule to make target `/var/tmp/portage/glibc-2.3.90.20060121/image//usr/include/bits/printf-ldbl.h', needed by `install-headers-nosubdir'.  Stop.
make[2]: Leaving directory `/var/tmp/portage/glibc-2.3.90.20060121/work/glibc-2.3.6/stdio-common'
make[1]: *** [stdio-common/subdir_install] Error 2
make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.90.20060121/work/glibc-2.3.6'
make: *** [install] Error 2

lnxz · Post by **lnxz** » Sat Jan 21, 2006 4:24 pm

I got the exact same error as the above poster.

satanskin · Post by **satanskin** » Sat Jan 21, 2006 4:30 pm

anyone had any issues with this glibc and the -Bdirect LDFLAGS in a chroot install. As mentioned here http://forums.gentoo.org/viewtopic-t-425183.html Nothing compiles with them for me.

nxsty · Post by **nxsty** » Sat Jan 21, 2006 4:40 pm

fca wrote: nano still gives a bus error for me, so no go.
But, I looked through the ebuild, and there is no mention of strncmp.S or something like that. I'll try adding the rm sysdeps/x86_64/strncmp.S line to the ebuild to see if that fixes the problem.

Perhaps you downloaded from one of the mirrors? They are only synced once per day so they still have the older version.

nxsty · Post by **nxsty** » Sat Jan 21, 2006 4:42 pm

PrakashP wrote:
but the file is missing. Is your snapshot incomplete?

Yes, seem like I didn't update the sources properly. I've uploaded a new branch update that should fix it. It takes a while to compile on my crappy 450mhz server so I didn't know it was broken until now. Just delete the branch update from the distfiles and regenerate the md5sums and it should get the new one.

fca · Post by **fca** » Sat Jan 21, 2006 4:56 pm

nxsty wrote:
fca wrote: nano still gives a bus error for me, so no go.
But, I looked through the ebuild, and there is no mention of strncmp.S or something like that. I'll try adding the rm sysdeps/x86_64/strncmp.S line to the ebuild to see if that fixes the problem.
Perhaps you downloaded from one of the mirrors? They are only synced once per day so they still have the older version.

I downloaded them from http://snigel.no-ip.com/~nxsty/linux/gl ... ay.tar.bz2 , I thought that was the main site.
With the added rm line, nano doesn't crash anymore. Everything seems OK now! Many thanks.

der Mosher · Post by **der Mosher** » Sat Jan 21, 2006 5:43 pm

The new version compiled fine here, now.

nxsty · Post by **nxsty** » Sat Jan 21, 2006 6:13 pm

fca wrote:I downloaded them from http://snigel.no-ip.com/~nxsty/linux/gl ... ay.tar.bz2 , I thought that was the main site.
With the added rm line, nano doesn't crash anymore. Everything seems OK now! Many thanks.

Damn I must stop smoking crack or something. I had done everything except actually uploading the tarball. But it's fixed now, for real this time!

PrakashP · Post by **PrakashP** » Sat Jan 21, 2006 7:36 pm

satanskin wrote:anyone had any issues with this glibc and the -Bdirect LDFLAGS in a chroot install. As mentioned here http://forums.gentoo.org/viewtopic-t-425183.html Nothing compiles with them for me.

Your chroot binutils need to be up-to-date, otherwise no go.

PrakashP · Post by **PrakashP** » Sat Jan 21, 2006 8:18 pm

Great! Now it emerged and nano isn't segfaulting anymore.

Thx alot!

Martigen · Post by **Martigen** » Sun Jan 22, 2006 1:47 am

nxsty wrote: Damn I must stop smoking crack or something. I had done everything except actually uploading the tarball. But it's fixed now, for real this time!

You must be smoking it a lot nxsty, check your changelog dates

nesl247 · Post by **nesl247** » Sun Jan 22, 2006 5:34 pm

I have a problem compiling mozilla-firefox. I had thought it was due to gcc but I am beginning to think that it is due to glibc. I think glibc because this part comes from a function right after including setjmp.h belonging to glibc.

This is the error:

Code: Select all

i686-pc-linux-gnu-g++ -o nsStackFrameUnix.o -c -I../../dist/include/system_wrappers -include ../../config/gcc_hidden.h -DMOZILLA_INTERNAL_API -DOSTYPE=\"Linux2.6\" -DOSARCH=\"Linux\" -DBUILD_ID=2006011815 -D_IMPL_NS_COM  -I../../dist/include/string -I../../dist/include/xpcom -I../../dist/include -I../../dist/include/nspr    -I/usr/X11R6/include   -fPIC  -DGENTOO_NSPLUGINS_DIR=\"/usr/lib/nsplugins\" -DGENTOO_NSBROWSER_PLUGINS_DIR=\"/usr/lib/nsbrowser/plugins\"  -I/usr/X11R6/include -fno-rtti -fno-handle-exceptions  -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -march=k8 -pipe -Wno-return-type -w -freorder-blocks -fno-reorder-functions -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -ffunction-sections -O2  -DGENTOO_NSPLUGINS_DIR=\"/usr/lib/nsplugins\" -DGENTOO_NSBROWSER_PLUGINS_DIR=\"/usr/lib/nsbrowser/plugins\"  -I/usr/X11R6/include -DMOZILLA_CLIENT -include ../../mozilla-config.h -Wp,-MD,.deps/nsStackFrameUnix.pp nsStackFrameUnix.cpp
nsStackFrameUnix.cpp: In function 'void DumpStackToFile(FILE*)':
nsStackFrameUnix.cpp:101: error: 'JB_BP' was not declared in this scope
gmake[3]: *** [nsStackFrameUnix.o] Error 1
gmake[3]: Leaving directory `/var/tmp/portage/mozilla-firefox-1.5-r9/work/mozilla/xpcom/base'
gmake[2]: *** [libs] Error 2
gmake[2]: Leaving directory `/var/tmp/portage/mozilla-firefox-1.5-r9/work/mozilla/xpcom'
gmake[1]: *** [tier_2] Error 2
gmake[1]: Leaving directory `/var/tmp/portage/mozilla-firefox-1.5-r9/work/mozilla'
make: *** [default] Error 2

!!! ERROR: www-client/mozilla-firefox-1.5-r9 failed.
!!! Function src_compile, Line 146, Exitcode 2
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

Has anything changed to cause this problem? I never had it before. It is either gcc itself (not my flags) or glibc and I am beginning to think glibc because no one else has problems with gcc4.1. Thanks

nxsty · Post by **nxsty** » Sun Jan 22, 2006 5:56 pm

nesl247 wrote:I have a problem compiling mozilla-firefox. I had thought it was due to gcc but I am beginning to think that it is due to glibc. I think glibc because this part comes from a function right after including setjmp.h belonging to glibc.

Which glibc do you run? I have no problems compiling firefox against 2.3.6.

nesl247 · Post by **nesl247** » Sun Jan 22, 2006 6:35 pm

2.3.90*

ianegg · Post by **ianegg** » Sun Jan 22, 2006 8:28 pm

Just to let you know, the string patch fix works perfectly here.

Horay!