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

Sun May 13 01:02:12 CEST 2007

Hi

On Sat, May 12, 2007 at 01:45:13PM -0700, Trent Piepho wrote:
> 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.

i dont disagree with everything you say, i just disagree where i know you
are wrong and anyway the things you say are from people like some
specific gcc developers, ulrich drepper and others, so really i disagree
with them more than i do with you, you just repeat what they say ...
i actually dont remember that i ever disagreed with a statement which was
originally from you

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

both of these are a matter of definition

if you define PIC as "moving" all "relocations" into tables then
yes my 2 statements which you took from past threads are wrong

if OTOH you define PIC as few relocations which is technically more sensible
then the statements are true

iam not disagreeing that the commonly accepted definition may be rather the
first
so if you claim that i was confused about the commonly accepted terminology
compared to technically sane definitions then iam not disagreeing
with you but the claim that i am confused about the technical details is
ridiculous

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

and here you are wrong, it is purely a limitation of the toolchain
we could play a game so i can proof it to you, just give me some simple C
code and ill give you some theoretically 64bit relocateable x86-64 code

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

iam not sure from which context you took that, it would be nice if you could
provide some link to the message from which you quote a sentance ...

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

well you touch it by mentioning, but you provide no arguments so i assume you
have none

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

i dont think i said that, what i said was

(note the RIP relative addressing is limited to 2^32 so no it cannot be used,
an extra register must be used, after all we do speak about the corner case of
more than 2^32 bit addressing and the compiler does NOT know if the address
of something after linking will be within 2^32 bit so i dont think it can
selectively choose RIP relative addressing)

please refrain from misrepresenting quotes

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

accessing a global variable using PIC by default does double indirection
most libs use that default
and with all the non portable tricks accesses to global vars of other DSOs
still need double indirection

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

true

> You just assumed there
> wouldn't be one. 

after reading the gcc manual and other people posting a vissiblity patch
and disscussing it without any hint to it yes i assumed that there was
no such option

> Even though there is a paper with a section on export
> control in DSOs that lists it. 

well, there are alot of papers, i cant read them all because one might
contain usefull information

> Seems like you love to hate gcc so much, you
> avoid any information that might not match your anti-gcc view.

not true but this is getting off topic

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- 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/20070513/90ea4ab3/attachment.pgp>