[MPlayer-dev-eng] Linking mplayer fails

[Xidorn Quan]

On Tue, Apr 2, 2013 at 2:26 AM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de>wrote:

> On 1 Apr 2013, at 13:57, Xidorn Quan <quanxunzhen at gmail.com> wrote:
> > However, I suggest to unconditionally add the PIC flag which is that
> > configure of ffmpeg actually does. It is obvious that compilation will
> > fail without this flag in many situations.
>
> Where do you see this in FFmpeg's configure?
> I just checked again and I am absolutely certain that FFmpeg uses the same
> logic as we do, the only difference is for features the other does not have:
> 1) FFmpeg enables PIC for shared libraries, but MPlayer can't be built as
> shared library, so this does not apply.
> 2) FFmpeg does not support PIE, so it has no handling for that.
>

My fault. You are right that FFmpeg uses the same logic.


> Please report the exact error you got.
>

The error is something like "error: macho: sorry, cannot apply 32 bit
absolute relocations in 64 bit mode, consider "[_symbol wrt rip]" for mem
access, "qword" and "dq _foo" for pointers." generated by yasm when
processing ffmpeg/libavcodec/x86/*.asm


> Also, does PIE actually work/have the desired effect on OSX?
>

According to my test, yes. This is my test code:

#if defined(__PIC__) || defined(__pic__) || defined(PIC)
> #   warning PIC enabled
> #else
> #   warning PIC disabled
> #endif
> int main() { return 0; }
>

and result:

$ clang test.c
> test.c:2:5: warning: PIC enabled [-W#warnings]
> #   warning PIC enabled
>     ^
> 1 warning generated.
>


> $ clang -fpie test.c
> test.c:4:5: warning: PIC disabled [-W#warnings]
> #   warning PIC disabled
>     ^
> 1 warning generated.
>

$ clang -mdynamic-no-pic test.c
> test.c:2:5: warning: PIC enabled [-W#warnings]
> #   warning PIC enabled
>     ^
> 1 warning generated.


$ clang -mdynamic-no-pic -fpie test.c
> test.c:4:5: warning: PIC disabled [-W#warnings]
> #   warning PIC disabled
>     ^
> 1 warning generated.


$ clang -m32 test.c
> test.c:2:5: warning: PIC enabled [-W#warnings]
> #   warning PIC enabled
>     ^
> 1 warning generated.


$ clang -m32 -fpie test.c
> test.c:4:5: warning: PIC disabled [-W#warnings]
> #   warning PIC disabled
>     ^
> 1 warning generated.


You may find from the result above that PIC is simply disabled by setting
PIE flag.

I also believe that it is a bug of clang since I tested gcc using the same
code, and the behavior is more reasonable: it always enables PIC by default
for all the commands listed.


> Do you know if this is with or without -mdynamic-no-pic?
>

This flag seems to have no effect to the default value of PIC.


> I presume this is building a 64 bit MPlayer binary, or also when building
> 32 bit?
>

I believe -march=corei7-avx indicates that it is building a 64bit one, and
output of configure also tells the arch is x86_64.


> I guess a fixed check of x86-64 and pie -> set config_pic would be ok,
> though strictly speaking it is not correct, it is possible (though rather
> pointless) to build a x86-64 toolchain that supports relocation without
> requiring PIC.
>

I agree that the former should work.


> A better way would be to actually test if linking non-PIC code actually
> works.
> Also, do you know if it is only the missing CONFIG_PIC that causes the
> linking failure or if we actually need to explicitly add -fPIC if we use
> PIE?
>

For me, it is not a linking failure. It fails when compiling as I mentioned
before. If I add -DPIC to YASMFLAGS in config.mak directly, it passes
compilation but fails to link.

-- 
Xidorn Quan
GnuPG fingerprint: 6F1E DF9A D250 7505 63E2  345E 7570 8D3F 7C9A 1209