Glibc 2.3 is out and prelinking support was added for ELF targets, startup times are significantly reduced (C++ and Qt/KDE applications will be most benefited from this – with this support on glibc there is no reason to revert to manual prelinking KDE which reportedly created stability issues). Read-only stdio streams now use mmap to speed up operation. The malloc functions were completely rewritten. The runtime now can handle the ELF thread-local storage (TLS) ABI on some platforms. This release has been ported to PowerPC64/Linux. Download it in a bz2 (13 MB) or gunzip (17.5 MB) tarball formats.
GNU C library 2.3 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I hope this one will be soon in gentoo, combined w/ gcc3.2 it should scream.
Hopefully they got rid of the arbitrary offset housekeeping crap… that drove me insane. And hopefully it’s no longer paging in unused blocks as it traverses the free list.
This definately is cause for examination, and perhaps excitement…
> with this support on glibc there is no reason to revert to manual prelinking KDE
You confuse objprelink with prelink? AFAIK the applications still have to be prelink’ed additionally. Red Hat 8.0 has a prelink 0.20-8 rpm (didn’t inspect it further yet, I only played with the last december prelink version 0.1.3).
IBM seems to be the only compan that is actually trying to push for linux support on other architectures than x86. Sun, HP, and SGI have all gone the way of Intel when it comes to Linux. IBM is working on the GPUL and, later, the Cell platform, which will likely be much better than Opteron and Itanium processors.
>You confuse objprelink with prelink?
Gulp, yes!
So similar words, and I wrote that immediately after I woke up today… Duh.
AFAIK, the C++/KDE problem mostly likes in the Linux loader… I wish someone would dive in the loader code and fix it, instead of making hacks like manual objprelinking, which results in instability (TrollTech strongly advises against it!)
Objprelinking is a hack. Prelinking is a work around that overcomes inherent problems in the ELF (and almost any other) shared library mechanism.
Interesting:
https://listman.redhat.com/pipermail/psyche-list/2002-October/000867…
Hopefully, this will get incorporated into distros quickly. On my Gentoo box (P4 2 GHz) loading konqueror to a null display takes about .382 seconds. Of that, linking takes about 650 million clock cycles, or approximately .325 seconds.
Anything to improve lookup time on shared libraries on any OS is a good thing IMHO.
Isn’t combreloc taking care of a lot of startup time (at least for the second start). This feature is used in older (not much older though) versions of redhat and probably other distributions as well.
Also, the big-start-up-time-apps like openoffice and mozilla did not like prelinking. Maybe that has changed recently (we might hope).
/Jarek
objprelink about halved kdes startup times on my system, and i guess i was lucky and didnt experience any problems with it.
But with gcc 3.1, and a new version of binutils (i cant remember the version), prelinking should be done automagically, and without the problems of objprelink.
At least this is how i understand it, which could very well be wrong
> I hope this one will be soon in gentoo, combined w/
> gcc3.2 it should scream.
Actually you’d need at least a current CVS version of GCC to support some of the new features.
One simple example is the new “_thread” keyword. Highly needed by the NPT library.
So don’t hold your breath yet.
SGI is pushing Linux on IA64, not x86.
“I wish someone would dive in the loader code and fix it”
Yes! …and I wish someone would look into binutils (most notably the linker) and fix the fact that GNU ld links in *all* the functions/data of a given .so instead of only the used functions/data — we’ve noticed this on MIPS for the embedded work we do at work and I’m pretty sure that PPC and x86 are the same way, IIRC. It would *significantly* reduce binary sizes.
Cheers,
Ken
> “I wish someone would dive in the loader code and fix it”
>
> Yes! …and I wish someone would look into binutils (most > notably the linker) and fix the fact that GNU ld links in > *all* the functions/data of a given .so instead of only
> the used functions/data — we’ve noticed this on MIPS for
> the embedded work we do at work and I’m pretty sure that
> PPC and x86 are the same way, IIRC. It would
> *significantly* reduce binary sizes.
What about ‘strip’???
>> What about ‘strip’???
Now comes the part of the “shut up and behave” :^P
ld shouldn’t be linking in any functions/data of a given .so, since the .so is dynamically linked. If you mean processing the relocations for only used symbols, this works for functions (procedures accessed via the PLT) but not for data (methods accessed via vtables) because the linker (in fact, no one) knows if a virtual function will be called until it actually gets called. Not processing all relocations for normal procedures will cause the code to jump to a stub function that can process that binding, but for data, not processing all relocations will cause the program to crash. There is nothing in the ELF standard that would allow the linker to distinguish virtual function tables (whose data could safely be lazy-linked) from regular data (which cannot be safely lazy-linked).