On Thu, Jan 8, 2009 at 15:42, Mark Glines <m...@glines.org> wrote:
> donald.hun...@gmail.com wrote:
>>
>> I was pretty averse to adding an additional configure step myself. The
>> problem is that warnings.pm checks specifically for supported compiler flags
>> and I didn't want to include other things there. The bug is that gcc.pm is
>> hardcoded for version 4.x rather than checking. I didn't want to add a
>> duplicate check for -fvisibility=hidden in this file.
>>
>> As I understand it, -fvisibility=hidden goes hand in hand with
>> __attribute__((visibility("default") so a single check covers both. If you
>> want to implement the fix as an explicit check for
>> __attribute__((visibility("default") in gcc.pm then that would work.
>>
>> Perhaps the simplest thing to do is just move my check into warnings.pm
>> after all. My guess is that it's never right to use -fvisibility=hidden
>> without also using __attribute__ ... so if one is used then the other needs
>> to be as well. That seems to be the best argument for keeping them in the
>> same place.
>
> Is there any version of gcc which accepts -fvisibility=hidden but not
> __attribute__((visibility("default")))? If not, then I'm worrying about
> nothing, and we can probably just use the existing check for both. But I
> agree, neither of these features makes much sense without the other.
>
decoupling is usually a good thing, but here i don't think it's worth
it. stick this functionality in an existing configure step.
~jerry
