[perl #62010] [PATCH] fix PARROT_EXPORT visibility=default for gcc other than 4.x

[Donald Hunter]

--0015174989f68b667c045ffbc194
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

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.

Cheers,
Donald.

[Mark Glines]

Post by Donald Hunter
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.

Mark

[Jerry Gay]

Post by Mark Glines

Post by Donald Hunter
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