[Ffmpeg-devel] build broken again...

Måns Rullgård mru
Tue May 10 11:17:58 CEST 2005

Michael Niedermayer <michaelni at gmx.at> writes:

> Hi
> On Tuesday 10 May 2005 02:56, M?ns Rullg?rd wrote:
>> Daniel Serpell <daniel_serpell at yahoo.com> writes:
>> > Hi!
>> >
>> > El Mon, May 09, 2005 at 11:46:39PM +0200, M?ns Rullg?rd escribio:
>> >> A non-PIC library, as the name implies, must be loaded a specific
>> >> address in memory.  The first time it is mapped, a text relocation
>> >> might fix the problem, but if another application needs the same
>> >> library, and already has mapped something else at that location, there
>> >> is nothing to be done, except making a new copy.
>> >
>> > Ah, seems you don't remember the "a.out" times, when distributions had
>> > to select non-overlaping address ranges to the libraries, so each copy
>> > could be shared. Common libraries had their addresses universally
>> > assigned.
>> I've seen attempts at such schemes in several old Unix versions.  In
>> addition to being inconvenient, it is bound to fail if the total size
>> of all libraries (on one system) should exceed the address space size.
> not on one system but loaded at the same time, and having more libs

Read what you're replying to.  This was about systems where the
library address regions must be coordinated since relocations are

> loaded then there is address space (which is probably more then
> physical ram) sounds like a bad idea to me

Address space and ram are not the same thing.  While being very bad
for performance, loading more libraries than there is physical ram is
certainly possible, but loading more libraries than there is address
space is obviously impossible.

> about being inconvenient, well IMHO the address decission can and
> should be done during load time not link/compile time

Certainly, and that's the way modern systems work.

M?ns Rullg?rd
mru at inprovide.com

More information about the ffmpeg-devel mailing list