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

Michael Niedermayer michaelni
Sat May 12 11:44:59 CEST 2007


On Fri, May 11, 2007 at 07:34:03PM -0700, Trent Piepho wrote:
> On Sat, 12 May 2007, Michael Niedermayer wrote:
> > On Fri, May 11, 2007 at 04:36:36PM -0700, Trent Piepho wrote:
> > > On Sat, 12 May 2007, Michael Niedermayer wrote:
> > > >
> > > > and to get this totally off topic disscussion a little back to ffmpeg,
> > > > i wish i could get gcc to make all symbols which arent in a specific set
> > > > of headers "library-wide static" anyone knows a simple and clean trick
> > > > to do that?
> > >
> > > Ulrich Drepper has a great paper on how to write DSOs that goes into this:
> > > http://people.redhat.com/drepper/dsohowto.pdf
> >
> > ive not read that and i wont, ive read enough from this guy to know that
> > id learn more by watching excel saga than by reading what he wrote ...
> I guess you shall continue to be confused about the differences between PIC
> and dynamic objects then.

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?

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 ...

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-
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

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 ...

For programmers the main advantage of the switch to
ELF was that creating ELF shared libraries, or in ELF-
speak DSOs, becomes very easy. The only difference be-
tween generating an application and a DSO is in the nal
link command line. One additional option (--shared in
the case of GNU ld) tells the linker to generate a DSO
instead of an application, the latter being the default.

yeah we never had a problem or compile failure due to
PIC/shared lib generation, it really is that easy
it also reminds me that rich couldnt compile python on his
system due to shared libs ...
maybe you and ulrich want to show him how easy it is to
build ELF shared libs on a clean system?

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,
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

> > 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?

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070512/8cbe0b69/attachment.pgp>

More information about the ffmpeg-devel mailing list