[FFmpeg-devel] PIC and YASM

Måns Rullgård mans
Sun Nov 8 20:02:31 CET 2009


Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:

> On Sun, Nov 08, 2009 at 01:16:39PM -0500, David Conrad wrote:
>> On Nov 8, 2009, at 9:35 AM, M?ns Rullg?rd wrote:
>> 
>> >Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>> >
>> >>On Sun, Nov 08, 2009 at 01:47:20PM +0000, M?ns Rullg?rd wrote:
>> >>>Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>> >>>
>> >>>>Hello,
>> >>>>I have been trying to figure out some compilation issues
>> >>>>with hardened
>> >>>>gentoo on AMD64 and they all come down to YASM.
>> >>>>Several issues:
>> >>>>-DPIC is and must be added explicitly to the yasm flags.
>> >>>>in particular:
>> >>>>--enable-pic will not add -DPIC to YASMFLAGS, nor will the
>> >>>>enable_pic
>> >>>>function. --enable-shared will though.
>> >>>
>> >>>That's easy to fix.  Does this work better?
>> >>
>> >>Probably, though why not just put it in the enable_pic function?
>> >
>> >Why litter a generic function with x86-specifics?
>> >
>> >>(x86inc.asm will unset it by itself where it is not supported)
>> >>I also suspect that my proposal will allow to get rid of that
>> >>"enable pic" hack for OpenBSD
>> >
>> >OpenBSD requires PIC.  Always.  End of story.
>> >
>> >>and the macho64 special-case.
>> >
>> >I don't know the story behind that one.
>> 
>> Mach-o doesn't support 32-bit absolute relocations on x86_64, only
>> 64-bit absolute which most instructions don't support.
>
> Well, but since there is no issue with the inline-assembly, that must
> mean that our inline assembly must be using PIC-relative addressing,
> which in turn must mean that one of __PIC__ __pic__ or PIC is defined,

Indeed, gcc on 32-bit OSX does defined __PIC__ by default.

-- 
M?ns Rullg?rd
mans at mansr.com



More information about the ffmpeg-devel mailing list