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

[Rich Felker]

On Sat, May 12, 2007 at 11:44:59AM +0200, Michael Niedermayer wrote:
> may i ask where exactly you think iam "confused"? or is it rather that you
> dissagree with my view about DSO and PIC and out of lack of arguments resort
> to this trolling?

If you have a view which contradicts those in power, expect to be
treated like this when you express it. :( In this community
(ffmpeg/mplayer) the Drepper philosophy is not so much in power, but
sadly it is in the "Linux community" at large.

> also ive no interrest to read this non free paper but to make you happy
> ill quote some of the nonsense of the first 2 pages, and iam not saying
> it doesnt contain valuable technical information but you can find that
> on other sources like wikipedia without ulrichs personal philosophy
> interleaved ...

Indeed..

> -
> No redistribution allowed.
> -
> ill hope ulrich doesnt mind me quoting and commenting on his text

:)))

> - (about a.out shared libs)
> 1. a central assignment of address ranges is needed;
> 2. collisions are possible (likely) with catastrophic re-
>    sults;
> -
> these points are mutually exclusive, if you have a central
> authority you have no collisions ...
> 
> also these nasty consequences result out of the limitation he imposes 
> _sevaral_ paragraphs prior (= no relocations at load not even if its just
> during the first load of the lib) instead out of limitations of a.out
> while he makes it look like its a consequence of a.out itself

Indeed, this is purely Drepper's anti-a.out trolling. Actually for a
long time BSD had a very nice a.out dynamic linker with relocations.
Much simpler and cleaner than the ELF abomination. Then Drepper
decided to kill it and force BSD to migrate to ELF by intentionally
breaking things in GNU binutils and making it difficult for the BSD
folks to keep their fork in sync... :(

> at least he is honest that:
> -
> This is probably faster than any other shared library implementation, ...
> -
> also something some people here dont want to accept ...

To be fair, the old Linux a.out dynamic linking method had a lot of
problems aside from the central address-space authority issue. It was
very hard to make ABI-compatible updates to libraries, and libraries
were hard to build without lots of hacks. Still, these issues could
have been addressed by asking the reasonable question: "What do we
need to be able to do that we can't currently do?" rather than the
unreasonable Java philosophy question "What's the most abstract
possible model we could possibly make that could do any idiotic thing
someone could imagine?"

I've spent a lot of time studying the history of dynamic linking and
relocation and trying to make a better dynamic linking approach for my
system. But for the time being I've been quite satisfied with static
linking, which has both optimal performance and optimal ABI-freeness,
and often also has optimal memory usage.

> -
> DSOs are today also often used as a way to
> structure programs. Different parts of the program are
> put into separate DSOs. This can be a very powerful tool,

This is the scariest part of Drepper's philosophy, and the reason why
Python is unusable for me... If they are used, DSOs should be treated
as a transparent replacement for normal libraries, not as a
first-order object to be manipulated by the program at runtime.

> especially in the development phase. Instead of relink-
> ing the entire program it is only necessary to relink the
> DSO(s) which changed. This is often much faster.
> -
> yes relinking at runtime, every time the program is loaded is
> faster than doing it once during compiletime, i love all these
> programs with 500 .so, they at least allow me to go and drink
> a glass of cola until the fast runtime linking is done while
> with the bad programs i cant even get off my chair

ROTFL :)))

> > > i want the ones in the public header to be vissible and the rest to be not
> > > so i just hmm  hmmm ...... don tell me they didnt have an option for the
> > > case 99.99% of the users of gcc would want but rather some odd feature which
> > > requires to change the whole source?
> > 
> > There is a pragma for that.  It's described in the paper you won't read.
> 
> the gcc options are described in the gcc manual and source or is the official
> gcc documentation now in non-redistributeable non-free papers?

:)

Rich