Tweaked glibc 2.4 + 2.5 + snapshot ebuilds

Message

nxsty · Post by **nxsty** » Wed Sep 20, 2006 1:31 pm

R-Type wrote:It looks like the latest glibc rev in toolchain_overlay doesn't support bbdirect/hashvals/dynsort. Has this been permanently phased out in favor of hash-styles? I have an amd64 system compiled with the bdirect 'trio' and I don't want to rebuild to hashstyles if a future patch will bring them back. Also, I read somewhere that bdirect is ostensibly compatible with hashstyles. Can they be safely merged?

Thanks for your efforts here. They've resulted in quite a speedup on my system. For the moment, I prefer the bdirect trio over hashstyles/prelink because they appear faster and there's less admin overhead (prelink).

It should be fixed now for the stable ebuild.

foolbaby · Post by **foolbaby** » Wed Sep 20, 2006 1:33 pm

work fine here after downgrade glibc to 2.4-r3

fik · Post by **fik** » Wed Sep 20, 2006 3:42 pm

nxsty wrote:
fik wrote:
fik wrote: Is there a way to go from glibc-2.4.90.20060805-r1 to glibc-2.4-r4?
I have commented the "Sanity check" directly in the glibc-2.4-r4.ebuild, now it is compiling, let's hope, it will not break my system.
Stuff compiled against the newer glibc might stop working. Keep a backup just in case!

In my case it is fine, no problems, maybe I was lucky

R-Type · Post by **R-Type** » Wed Sep 20, 2006 6:25 pm

nxsty wrote:
R-Type wrote:It looks like the latest glibc rev in toolchain_overlay doesn't support bbdirect/hashvals/dynsort. Has this been permanently phased out in favor of hash-styles? I have an amd64 system compiled with the bdirect 'trio' and I don't want to rebuild to hashstyles if a future patch will bring them back. Also, I read somewhere that bdirect is ostensibly compatible with hashstyles. Can they be safely merged?

Thanks for your efforts here. They've resulted in quite a speedup on my system. For the moment, I prefer the bdirect trio over hashstyles/prelink because they appear faster and there's less admin overhead (prelink).
It should be fixed now for the stable ebuild.

Ok, cool, but my Bdirect-enabled glibc is already 2.4.90.20060805-r1 and I read that downgrading glibc is a bad idea. That's why I asked if Bdirect and friends are dead. If they are, I'll migrate to hashstyles, but if not, I'll just wait.

Thanks for your help.

nxsty · Post by **nxsty** » Fri Sep 22, 2006 1:31 pm

R-Type wrote:
nxsty wrote:
R-Type wrote:It looks like the latest glibc rev in toolchain_overlay doesn't support bbdirect/hashvals/dynsort. Has this been permanently phased out in favor of hash-styles? I have an amd64 system compiled with the bdirect 'trio' and I don't want to rebuild to hashstyles if a future patch will bring them back. Also, I read somewhere that bdirect is ostensibly compatible with hashstyles. Can they be safely merged?

Thanks for your efforts here. They've resulted in quite a speedup on my system. For the moment, I prefer the bdirect trio over hashstyles/prelink because they appear faster and there's less admin overhead (prelink).
It should be fixed now for the stable ebuild.
Ok, cool, but my Bdirect-enabled glibc is already 2.4.90.20060805-r1 and I read that downgrading glibc is a bad idea. That's why I asked if Bdirect and friends are dead. If they are, I'll migrate to hashstyles, but if not, I'll just wait.

Thanks for your help.

There isn´t much I can do unless Michael Meeks releases an updated patch. The Bdirect/hashvals code conflicts with hash-style.

nxsty · Post by **nxsty** » Fri Sep 22, 2006 1:32 pm

Glibc 2.5 will be released on sep 29 btw.

irondog · Post by **irondog** » Fri Sep 22, 2006 2:11 pm

nxsty wrote:Glibc 2.5 will be released on sep 29 btw.

Nice. Are there any new features except the DT_GNU_HASH support in ld.so?

abhay · Post by **abhay** » Fri Sep 22, 2006 5:12 pm

nxsty wrote:Glibc 2.5 will be released on sep 29 btw.

What does it means for people like me who are still using the older hashvals, zdynsort and Bdirect system? Is it time to move on to your snapshot releases? Will there be any ABI change between the snapshots and the final release? If I recompile my whole system against the snapshot release, will I have to recompile again when the stable release comes out?

irondog · Post by **irondog** » Fri Sep 22, 2006 6:31 pm

On one of my systems I downgraded from 2.5 to 2.4 today. I've been running and building on 2.5 snapshots for a while now and I can assure you everything on my system was built against glibc 2.5. Downgrading works without any problems (except for the ebuild screaming murder), but I've found no breakage at all.

So it seems 2.4 is forward compatible with 2.5, or at least not many binaries use the new 2.5 features that are unavailable in 2.4.
Downgrading from 2.4 to 2.3.6 is a sure way to destruction though, you can try it for fun and it will. So, I'm not telling you you can downgrade safely to an acient glibc whenever you want.

If I recompile my whole system against the snapshot release, will I have to recompile again when the stable release comes out?

Rebuilding the whole system after a glibc update seems a little useless. Newer Glibc's are binary compatible with older ones. That's what the glibc devs strive for. Whenever things change heavily (in 2020, glibc 10.0) you have to rebuild everything, but such a thing can't be done with portage at all, cause portage depends on python built on the old glibc, etc, etc. So, don't believe everyone screaming emerge -e && emerge -e && emerge -e && emerge -e on these gentoo forums plz.

abhay · Post by **abhay** » Fri Sep 22, 2006 7:32 pm

irondog wrote:Rebuilding the whole system after a glibc update seems a little useless. Newer Glibc's are binary compatible with older ones. That's what the glibc devs strive for. Whenever things change heavily (in 2020, glibc 10.0) you have to rebuild everything, but such a thing can't be done with portage at all, cause portage depends on python built on the old glibc, etc, etc. So, don't believe everyone screaming emerge -e && emerge -e && emerge -e && emerge -e on these gentoo forums plz.

I understand what you are saying but the situation in my case is a little different. I am using a system with older LDFLAGS made of hashvals, zdynsort and Bdirect. nxsty removed these patches from the newer snapshots and added hash-style. afaik this made the newer snapshots ABI incompatible with old one. Am I thinking right or have some weird thoughts in my head?

Gergan Penkov · Post by **Gergan Penkov** » Sat Sep 23, 2006 2:09 pm

this has nothing to do with glibc or with new features in glibc, you will need to rebuild world after updating the linker and not implicitely after updating glibc.
the hashtyle flag simply adds a new section in the linked libraries, which is the thing you want, the glibc has the loader for these feature - so it could be emerged as the last thing.
and it seems that the hashstyle glibc loader could break with the -Bdirect layouted libraries.

irondog · Post by **irondog** » Sat Sep 23, 2006 4:31 pm

Gergan Penkov wrote:this has nothing to do with glibc or with new features in glibc, you will need to rebuild world after updating the linker and not implicitely after updating glibc.[...]

Agreed.

We started discussing about what to do when 2.5 is getting out and I was telling that this won't require you to rebuild world.

Gergan Penkov · Post by **Gergan Penkov** » Sat Sep 23, 2006 6:27 pm

I commented, as it seems that there is general misunderstanding about hashstyle, glibc does not have any influence on the code-generation and the linking, in this case. It simply uses this linker-generated information, if available, to load the libraries/binaries

Probably this comes from the hashstyle-thread where we have had concerns about the numerous releases, which were incompatible. Even then the problem was to be able to rebuild all the pkgs without turning on the (old)new features in the glibc-loader. In the moment there are no new releases of the linker and I don't think they'll change the format of the section for years to come, so rebuilding world after glibc update, because of fear that the hashstyle-format could have been changed is absolutely without any basis.
Of course, rebuilding world, because of switching from -Bdirect or because of adding the hashstyle-linkerflag is still necessary.

abhay · Post by **abhay** » Sun Sep 24, 2006 8:14 pm

Gergan Penkov wrote:Of course, rebuilding world, because of switching from -Bdirect or because of adding the hashstyle-linkerflag is still necessary.

well that makes it all clear for me. what i understand is that "rebuild the first time i.e. after changing to LDFLAGS and no need to recompile again"

nowinter · Post by **nowinter** » Tue Sep 26, 2006 11:09 am

After some messing I have two versions of binutils on my sytem: 2.17 from the nxsty's overlay and 2.17.50.0.3 unmasked from the tree. I understand one of them supports hash-style while the other is engineered to work with Bdirect. Moreover, in my make.conf both -Bdirect and hash-style=both are present. I use nxsty's glibc-2.4-r4. What will actually happen? I couldn't understand if my packages are compiled and linked with Bdirect or hashvals/dynsort? Stuff doesn't seem to break so far, ie compile with both options in LDFLAGS goes smoothly. Can someone help a newb here?

UPDATE: sorry, I issued binutils-config and realized the active profile consists just of 2.17. But, again, what does it say about LDFLAGS I use?

another UPDATE: no, it seems to be only Bdirect in use now.. I perhaps should just unmerge 2.17.50.0.3.

n0rbi666 · Post by **n0rbi666** » Sat Sep 30, 2006 9:35 pm

glibc-2.5 is in portage ...
Is it safe to use it with --hash-style ?

jarealist · Post by **jarealist** » Sat Sep 30, 2006 9:49 pm

glibc-2.5 has NPTL_KERNEL_VERSION=${NPTL_KERNEL_VERSION:-"2.6.9"}, whereas 2.4.90.20060915 has NPTL_KERNEL_VERSION=${NPTL_KERNEL_VERSION:-"2.6.16"}.

I'm using --hash-style=both, can I just modify the glibc-2.5 ebuild NPTL_KERNEL_VERSION line to "2.6.16" or should I just stay with the portage 2.5 ebuild as is?

nxsty · Post by **nxsty** » Sun Oct 01, 2006 12:56 pm

jarealist wrote:glibc-2.5 has NPTL_KERNEL_VERSION=${NPTL_KERNEL_VERSION:-"2.6.9"}, whereas 2.4.90.20060915 has NPTL_KERNEL_VERSION=${NPTL_KERNEL_VERSION:-"2.6.16"}.

I'm using --hash-style=both, can I just modify the glibc-2.5 ebuild NPTL_KERNEL_VERSION line to "2.6.16" or should I just stay with the portage 2.5 ebuild as is?

Yes you can, but it´s easier to just add NPTL_KERNEL_VERSION to your make.conf instead.

nesl247 · Post by **nesl247** » Sun Oct 01, 2006 12:57 pm

nxsty, any timeframe on updated ebuilds?

weedy · Post by **weedy** » Mon Oct 02, 2006 7:48 am

do the patches in 2.4.90.20060915 add anything that portage 2.5 doesnt have?

nxsty · Post by **nxsty** » Mon Oct 02, 2006 1:14 pm

weedy wrote:do the patches in 2.4.90.20060915 add anything that portage 2.5 doesnt have?

Only nomalloccheck and the suse madvise patch that allows glibc to tell the kernel if loaded libraries are expected to be needed in the near future (should improve performance in some situations).

Since glibc 2.5 is in portage now I'm not sure there is any point maintaining this anymore. Most of the changes are minor. Kernel version can be set in make.conf, nomallocheck can be set by a env variable, -Bdirect is obsolete and I don't think the madvise patch and -DNDEBUG=1 is that important.

But I will sync the ebuilds anyway for now.

vipernicus · Post by **vipernicus** » Mon Oct 02, 2006 1:18 pm

nxsty wrote:
weedy wrote:do the patches in 2.4.90.20060915 add anything that portage 2.5 doesnt have?
Only nomalloccheck and the suse madvise patch that allows glibc to tell the kernel if loaded libraries are expected to be needed in the near future (should improve performance in some situations).

Since glibc 2.5 is in portage now I'm not sure there is any point maintaining this anymore. Most of the changes are minor. Kernel version can be set in make.conf, nomallocheck can be set by a env variable, -Bdirect is obsolete and I don't think the madvise patch and -DNDEBUG=1 is that important.

But I will sync the ebuilds anyway for now.

What is the purpose of the madvise patch?

nxsty · Post by **nxsty** » Mon Oct 02, 2006 2:02 pm

vipernicus wrote:What is the purpose of the madvise patch?

This mail explains it: http://sourceware.org/ml/libc-alpha/200 ... 00135.html

It was rejected because suse didn't provide any benchmarks but it's still included in their glibc.

mbar · Post by **mbar** » Mon Oct 02, 2006 2:26 pm

Is hashstyle merged into glibc 2.5?

nowinter · Post by **nowinter** » Mon Oct 02, 2006 2:43 pm

nxsty wrote: -Bdirect is obsolete

I thought it is your ebuild, namely 2.17, that makes use of -Bdirect, and the one I actually use (although I also have 2.17.50.0.3). Does what I quoted mean I should make use of -hash-style only perspectively? I must have missed something in this thread.

Tweaked glibc 2.4 + 2.5 + snapshot ebuilds

both -Bdirect and -hash-style ?