The original post about it was posted by a developer, so I think that they already know. Also, I notice a much higher speed increase with LDFLAGS over prelink. Compared to LDFALGS, prelink is unnoticable.

I (think?) that this would only speed up apps not libraries. But I could be totally way off base. Anyone have any ideas about this?

By the way. I have put this in my make.conf and so far it has not caused any errors in the packages that have been built against it. It does seem to make the build time itself a little longer but that could be all in my head.

Good stuff so far. Thanks again for bringing this to our attention aethyr!_________________Gentoo: it's like wiping your ass with silk.

The original post about it was posted by a developer, so I think that they already know. Also, I notice a much higher speed increase with LDFLAGS over prelink. Compared to LDFALGS, prelink is unnoticable.

Also, this should not harm your programs at all.

Could one these optimizations together with prelinking? Would it make any sense?_________________My tech-blog | My other blog

I don't know what the security risk actually is, but it's probably a good idea to do what it suggests _________________Per Ardua Ad Astra
The Earth is the cradle of the mind, but we cannot live forever in a cradle - Konstantin E. TsiolkovskyGentoo Radeon FAQ

It looks like there are more packages which give similar warnings. Try grepping for something like "QA Notice: Security risk" in /var/log/portage. My emerge -e world is still running, but these are the ones that had already been compiled:

Code:

cups
glibc
pam
shadow
sudo
utempter
xterm

_________________Per Ardua Ad Astra
The Earth is the cradle of the mind, but we cannot live forever in a cradle - Konstantin E. TsiolkovskyGentoo Radeon FAQ

Security feature. suid binaries should not allow LD_{PRELOAD,DEBUG} and
therefore be relinked in "immediate" mode rather than "lazy". That
resolves the library links and function calls -before- running the
application rather than "as needed".

Somone (solar?) Decided it was a good idea to sharpen up the packages.
The fix is to fix the ebuild that installs a suid binary to axtually "do
right".

Last edited by aethyr on Thu Sep 23, 2004 3:47 pm; edited 3 times in total

How exactly? I was just about to run emerge -e world, when I noticed that. And since KDE and it's apps are what I run 95% of the time, it's pretty important to me_________________My tech-blog | My other blog

Not adding support for [LDFLAGS] would make some of the work I do for gentoo linux moot.

For what it's worth, I recompiled GNOME 2.8 with it and I had no problems, other people seem to be ok so far with "emerge -e system". Hopefully if there are problems (which I haven't heard about yet, aside from that 1 remark) with this feature in portage it can be resolved.

Evangelion wrote:

Quote:

<solar> KDE iirc hates LDFLAGS=

How exactly? I was just about to run emerge -e world, when I noticed that. And since KDE and it's apps are what I run 95% of the time, it's pretty important to me

Evangelion, why not emerge something like kdeutils and see if there's a problem? If worst comes to worst, just comment out the line in make.conf and emerge it again.

[edit] I think Solar might have been addressing this:
Usenet Post
Which does have to do with KDE and LDFLAGS, but has nothing at all to do with "-Wl,-O1". If that's the case, then I think you're OK.

Evangelion, why not emerge something like kdeutils and see if there's a problem? If worst comes to worst, just comment out the line in make.conf and emerge it again.

As you wish sir. I'm now emerginh KDE-utils. I disabled prelinking. If KDE-utils work with these new optimizations, I will try enabling prelinking again. If everything works, I'll do emerge -e world, with or without prelinking (depending that does it help/work)

If everything works, I'll do emerge -e world, with or without prelinking (depending that does it help/work)

hehe, you seem very excited about doing "emerge -e world". If kdeutils works, why not try a few more KDE packages and see what the effects are? Then maybe you'll be able to post some benchmarks as well, with and without LDFLAGS. I tested about 6 packages before I reemerged GNOME and I still haven't done "emerge -e world". I'll probably just leave it in my make.conf and let the change propagate as I keep my system up to date.

I tired it with Koffice (without prelinking). Now, benchmarking was really difficult since the apps loaded in 2-3 seconds to begin with. I think that performance is more or less the same. Certainly not worse than it was. And the apps work just fine. It _might_ be a bit better.

I guess I would have to recompile Qt and KDElibs to get any noticeable improvement_________________My tech-blog | My other blog

I tired it with Koffice (without prelinking). Now, benchmarking was really difficult since the apps loaded in 2-3 seconds to begin with. I think that performance is more or less the same. Certainly not worse than it was. And the apps work just fine. It _might_ be a bit better.

I guess I would have to recompile Qt and KDElibs to get any noticeable improvement

The way I've been testing is to run the app with "time application" and then immediately close it as soon as possible (basically hold the mouse pointer over where the close button appears and then click ASAP). There's probably much better ways to do it though...

If I was testing KOffice, I'd start it ~10 times without "-Wl,-O1", average out those 10 times, and then start it 10 times with "-Wl,-O1" and average out those times. The trickiest part is timing the window close. Sometimes you'll totally miss it, I just disregard those runs (i.e. only keep runs where the window was closed as soon as it popped up).

You might want to test with and without prelinking as well, for a total of 4 tests.