From: pmacdona@sanjuan (Peter MacDonald) Subject: Re: 386 BSD Date: Wed, 6 Jan 1993 20:43:04 GMT
In article <1993Jan6.175208.11119@sfu.ca> rchen@fraser.sfu.ca (Robert Chen) writes:
>In article <1993Jan6.085905.25749@klaava.Helsinki.FI> lukka@klaava.Helsinki.FI (Tuomas J Lukka) writes:
>>In article <C0F8L6.AB4@ux1.cso.uiuc.edu> Jeff-Randall@uiuc.edu (Jeff Randall) writes:
...
>>No, not yet. They're in the works, by a mailing list on ref.tfs.com,
>>386bsd-sharedlibs. The implementation is going to be rather high-tech
>>(non-kludged). The current linux shared libraries do their job but
>
>Non-kludged? I doubt that those on the GCC channel would agree with
>your implication about the *working* linux shared library implementation.
Not to perpetuate a flame war, but let me point out something. Every
so often, the current Linux shared libs are bashed by the puritans
because it is not plug and play for the library builders to
generate the shared libs (and also that they sit at a fixed
address).
Assuming that the fixed location is not a major hardship at this point,
(what, only 1.5 Gig per process, outrageous), the fact that library
builders have to work harder than an elegant solution would require,
shoudn't be an issue: lib builders are only a small fraction of the
user base, lets say 5%. Is an elegant solution that penalizes 95% of
the users, with say a 30% penalty, to save 5% of the users some work,
a good idea?
I do not wish to dispute the above figures. I am rather just
stepping back and looking at the bigger picture. If an elegant
and practical solution is demonstrated, I will be the first to
jump on the bandwagon. But being set back a month to collect
and recompile all of the system again won't make me to happy
either. Hopefully, the new and old schemes (if a new one appears)
will coexist, at least for a while.
Peter