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

Trent Piepho xyzzy
Sat May 12 22:45:13 CEST 2007

On Sat, 12 May 2007, Michael Niedermayer wrote:
> 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?

It seems to me the other way around.  You feel a need to disagree with
anything I say, even when you don't know much about the subject.

But let's see, what have you been confused about:

Using -fpic with gcc will make your asm code position independent.  It won't.

Using textrels (text relocations) is a way to create PIC code.  It's not, it's
an alternative method of allowing code to be relocated.  The whole point of
PIC is to _avoid_ textrels!

x86-64's lack of support for textrels is entirely a limitation/bug of the tool
chain.  It's not, it's a limitation of the architecture.

64-bit displacements are required unless _all_ shared libraries are loaded
under 4GB.  Not true, 64-bit displacements (not even supported by gcc yet) are
only needed to create one object larger than 4GB.  32-bit displacements are
enough for multiple objects <4GB that together are spread across a >32-bit
address range.

Loading all DSO's at a system wide fixed address under 4GB is feasible.  I'm
not even going to touch that, just post it to lkml.

x86-64 can't use rip relative addressing to create PIC code.  It can and does,
just look at the asm output.

Accessing a global variable using PIC code requires double indirection via the
GOT.  Not true.  The extra indirection is for accessing a symbol from a
different DSO.  PIC only requires the use of an extra register holding the
base address in the address calculation.

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

It's the best compilation of technical information on how DSOs work on Linux
and other unix systems and how to make them faster I've seen.  The wikipedia
article on shared libraries is just a non-technical overview (and a link to
that paper).

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

I think it's implied that 2 is what happens if you don't always use 1.

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

Who said a.out wasn't faster?  a.out is fast and simple and ELF is complex,
there's really no question about that.  For all its strengths, I don't see
anyone maintaining an a.out distribution.

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

I thought Rich's problem was the he didn't want to use shared libs and the
python build system didn't have an option for that.

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

The point is you didn't know that option existed.  You just assumed there
wouldn't be one.  Even though there is a paper with a section on export
control in DSOs that lists it.  Seems like you love to hate gcc so much, you
avoid any information that might not match your anti-gcc view.

More information about the ffmpeg-devel mailing list