[FFmpeg-devel] Why 'You can only build one library type at once on MinGW'?

[Rich Felker]

On Mon, May 14, 2007 at 04:22:25PM +0200, Panagiotis Issaris wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> Rich Felker wrote:
> >[...]
> > for a larger program. But the idea of an object >4gig is pure pedantry
> > since it does not exist and will never exist.
> 
> This is a dangerous statement to make :) unless you like being ridiculed
> in 2094 ;->

No, designing a huge complex program as a single process with a single
address space is fundamentally flawed. This will not change, at least
not for humans; it's an invariant of the human brain what degree of
complexity is able to be processed. When a system becomes larger than
that, the correct solution (after first asking whether the largeness
is really necessary and reconsidering the problem if it's not) is to
abstract, refactor, etc. into components, and probably also to use a
different language as part of this process. At that point, having all
the components share a single unprotected memory space is just asking
for bugs and vulnerabilities. Certainly it's utterly impossible to
audit such a program. The only hope of making a robust program that
large is to compose it out of (relatively) trivial components which do
not have access to one another's memory space and which are subjected
to strong protections and privilege levels.

> > [...]
> >> C89 doesn't say anything about inline asm, can that be used?
> > 
> > No, never as the only implementation of something. Only as an optional
> > optimization for use when compiling on a particular compiler/host
> > combination.
> 
> Translation: "Yes. But only if there's a fallback C implementation."

Exactly.

> >> C89 doesn't
> >> say anything about shared libraries or dynamic linking or memory models,
> >> so any optimization relating to those can't be used?
> > 
> > A good program cannot be dependent on them, no.
> 
> Translation: "No. Because I do not like them."

No, the translation is just like for inline asm: "Only if there's a
fallback C implementation."

> Joking aside, this means that using "optimizations" related to shared
> libraries would be okay for you if they are optional?

Of course, as long as functionality is not crippled. Polluting the
namespace is crippled functionality because it makes it impossible to
use the library with applications where there are clashes.

Rich