You are not logged in.
Pages: 1
I certainly don't understand the innerworkings of Arch as much as others but this certainly seemed interesting.. is this something that Arch might evaluate or try?
I am a gated community.
Offline
It looks interesting. I only don't understand why that isn't the default behaviour...
Offline
hmmm that's interesting - however we are just looking at symbols in the library... they may or may not be loaded... can someone test this and give me any statistics... I'm looking at load times and file sizes...
though load times may be difficult to test... try with firefox or something...
Offline
It probably won't make any big speed difference, but apps refuse to startup if a library to which it is linked isn't installed. This options only links the app to the libraries really used by that app, instead of all in the ld option.
stonecrest, open a new bugreport (featurerequest) and ask Arch to implement this (that is, use this as the default compile option).
Offline
Yeah, it can be added to makepkg.conf in the CFLAGS section...
But I know a few apps which will start fine with missing libs (firefox I know for sure... I spent alot of time tracking down why libgnome causes it to crash for me... *shrug*)...
the thing is, standard practice uses RTLD_LAZY when loading so's and so symbols aren't loaded until they are needed - I think that if no symbols are used in a library, it may never be loaded into memory, though this is speculation...
So if that's correct, the only speed difference will be resolving the location of the modules, which should be done already (cached ld.so stuff)...
I'm just curious if this makes a difference in the size of the elf header...
Offline
It hasn othing to do withresolving symbols, an executable has a list of libraries it needs, and if those aren't there then it doesn't start up. Perhaps if an unneeded lib is missing then it will start up anyway, I don't know (I doubt it though).
That ldd gives missing libs on Firefox doesn't mean they are really missing. Firefox uses a different library path.
Offline
It hasn othing to do withresolving symbols, an executable has a list of libraries it needs, and if those aren't there then it doesn't start up. Perhaps if an unneeded lib is missing then it will start up anyway, I don't know (I doubt it though).
ah, yeah good point - i forgot libs were flagged as NEEDED and UNNEEDED in the header...
so does the "--as-needed" link switch actually remove the listing from the headers, or simply switch it from NEEDED to UNNEEDED?
Offline
$ man ld
...
--as-needed
--no-as-needed
This option affects ELF DT_NEEDED tags for dynamic libraries men-
tioned on the command line after the --as-needed option. Normally,
the linker will add a DT_NEEDED tag for each dynamic library men-
tioned on the command line, regardless of whether the library is
actually needed. --as-needed causes DT_NEEDED tags to only be emit-
ted for libraries that satisfy some reference from regular objects.
--no-as-needed restores the default behaviour.
...
As it seems so obviously the sensible thing to do, I don't understand that it isn't the default behaviour...
Offline
yeah, good point - why is that even an option?
maybe, namcap can be updated as well to use readelf output instead of ldd - it will help lower some of the dependancy hell that's been going on with some of the larger packages...
Offline
I think this will be done in the very near future.
GCC 4.0.0 forces us to provide a glibc snapshot taken from Fedora, which forces AS_NEEDED in everything that links against /usr/lib/libc.so (so basicly everything ).
The AS_NEEDED keyword in that file isn't supported by standard binutils, but requires a patched binutils. I also built this beast and it seems to do its job OK.
Yesterday I did some tests with the glibc 2.3.5-snap, gcc 4.0.0 and binutils 2.15.92.0.2.2 + fedora patches, and the results were nice: a package that usually takes up 7MB on the system became 10% smaller, which is a good thing for a package that contains many pixmaps, pngs and HTML docs.
Offline
Pages: 1