What ELF needs is something like the (byzantine) a.out stub
generator, where you gave it an explicit list of symbols to
export. This would cut down on the distressing usage of
private symbols.
>> I statically link every elf program I have to use these days,
>> because it's the only way to guarantee that it will work.
>> It adds ~250k to each and every binary, which isn't perfect,
>> but in the land of 128mb memory sticks costing US$180 is a
>> lot faster than writing a completely new libc and trying to
>> get other people to use it.
>
>Probably, but I thin we've argued about this in the past - ncurses,
>remember? I think even in those times of aplenty one should strive for
>efficiency.
If the infrastructure was there, I'd cheerfully use shared libraries.
But for shared libraries to work, you need to have a fixed published
interface and some assurance that features will keep working when
you changed libraries.
>> How many _programs_ are in the SO suite?
>
>Just one big program!
So SO would add ~250k to the size of their code by statically
linking to libc? And they'd gain independence from the library
of the week club? This looks like an unqualified win to me.
____
david parsons \bi/ Now a statically linked X3.3.3 will dump core trying
\/ to do dlclose. Sigh. X is evil(tm).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/