Re: configure level change on arm to build PIC until glibc-2.2?
On Mon, 28 Aug 2000, Philip Blundell wrote:
> Not a lot. If you want to use a shared object purely as a way of dynamically
> loading code, and don't actually want to share it, it can be slightly more
> efficient to build it non PIC. But the vast majority of cases of non-PIC code
> in shared objects happen by mistake, either because they want to include
> code from some other library (-liberty, say) that isn't built PIC, or because
> they just plain forget to use -fPIC.
Okay, I thought it was my knowledge that was lacking.
So non-PIC binaries are of the type `reloctable once and fixed-up forever',
then? And thus the binaries emitted by `gcc' without any particular
flags don't assume a fixed base address, then?
In the old NetBSD/arm32 1.0 world, I remember there was a stage when
a bunch of binaries needed a recompile to a different base addresses,
because more space was being made for the page maps (or something like
that). And that's where my assumption stuck.
Will stuff loaded by dlopen() and friends automatically get the benefit
of sharing if compiled with `-fPIC'? That is, if I have N copies of
some program which makes use of dynamically-loaded components (perhaps
the GIMP, if it functions like that -- I don't know), what determines
without those components get shared?
Is it all down to mmaping a region without PROT_WRITE?
c.
Reply to: