On Sunday, November 25, 2012, Måns Rullgård <[email protected]> wrote:
> Sean McGovern <[email protected]> writes:
>
>> Greedy compiler option parsing in Solaris Studio make this option
>> do bad things to the resulting shared library.
>> ---
>>  configure | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index 8b68bbc..10c714d 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2748,7 +2748,7 @@ case $target_os in
>>      sunos)
>>          AVSERVERLDFLAGS=""
>>          SHFLAGS='-shared -Wl,-h,$$(@F)'
>> -        enabled x86 && SHFLAGS="-mimpure-text $SHFLAGS"
>> +        enabled_all gcc x86 && SHFLAGS="-mimpure-text $SHFLAGS"
>>          network_extralibs="-lsocket -lnsl"
>>          add_cppflags -D__EXTENSIONS__ -D_XOPEN_SOURCE=600
>>          # When using suncc to build, the Solaris linker will mark
>> --
>
> I think this is wrong.
>
> First some background.  When creating a shared object, gcc on Solaris by
> default passes "-z text" to the linker, which makes relocations against
> read-only sections an error.  The -mimpure-text flag tells the gcc
> frontend not to do this, thus allowing text relocations in the shared
> object.  On x86-32, we deliberatly use some text relocations even in
> shared objects due to the high overhead of PIC there.  From what I can
> tell, suncc defaults to allowing text relocations in shared objects.
>
> Considering the above, we need to use -mimpure-text when creating shared
> objects with gcc on x86-32.  The correct line should thus be this:
>
> enabled x86_32 && test $ld_type = suncc && append SHFLAGS -mimpure-text
>

Hi Mans,

As always thank you for the review.

Poking around the documentation for suncc and the Solaris linker shows that
the SHFLAGS settings are wrong for anything that isn't GCC. I haven't
started running shared builds with suncc until now.

I will attempt to re-work this section. Stay tuned!

-- Sean McG.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to