Re: Patch not included in e2fsprogs 1.21.

[Theodore Tso <tytso@mit.edu>]

On Sun, Jun 17, 2001 at 12:27:57PM +0100, Philip Blundell wrote:
> >Isn't PIC used for a reason in shared libs? :)
> 
> Sure it is, but that reason doesn't really apply here.
> 
> The reason we compile shared libraries as PIC is so that many
> applications can map the same object at different addresses and have
> only one copy of the code in memory.  PIC code is slightly bigger,
> and slightly slower, but it's worth it because you avoid the need to
> have duplicated code all over the place at run time.

Will, if you just need a .a file containing non-PIC objects, then why
not just use libext2fs.a?  (Because of the bug, libext2fs_pic.a was
exactly the same as libext2fs.a, which is why I rejected the patch.)

<slightly off-topic side-comment>

The GNU dynamic loader can actually deal with non-PIC shared
libraries?!?  I didn't know that.....  If so, then it shouldn't be
that hard to do a hack which OSF/1 one uses, which allows you to use
non-PIC code on a production system.  The trick which OSF/1 uses is
that it has a configuration file in /etc which contains starting
addresses for shared libraries so that they won't conflict with one
another.  (This file is constructed at the equivalent of ldconfig
time, along with a cached copies of libraies already pre-relocated to
their system default location.)  The major win to this is that you
don't have to take the performance hit of PIC code, while still being
able to use shared libraries.  It's somewhat like the old a.out DLL
shared libraries, except that instead of having a global address
registry maintained by Eric Youngdale (which couldn't possibly be able
to scale), the address registry is maintained on a per-system basis.

If someone is interested trying to take this on as a project, and is
familiar with the low-level details of the dynamic linker, that would
be great.  I'd love to chat with you about how things are done under
OSF/1 and the old a.out jumptable shared libraries, and how we might
be able to get the benefits of OSF/1, a.out, as well as the current
ELF shared libraries all in one package.  I don't know if it's doable,
but it would be really, really, cool if it could be done.

</slightly off-topic side-comment>

							- Ted