Re: [PATCH,Darwin, config] Fix PR70694; don't force visibility on inlines for Darwin > 8

2018-08-24 Thread Jonathan Wakely

On 24/08/18 16:09 +0100, Iain Sandoe wrote:

At some point, with the toolchain components available to Darwin8, it was
preferable to force everything generated by headers to be hidden.
However, the work-around wasn’t limited and it has caused Darwin x86/x86_64
to have a blanket application of  "-fvisibility-inlines-hidden” ever since.

Since, in libstdc++, the visibilities are specified explicitly and the flag
causes code to be hidden that is intended to be visible.  This causes a lot of
warnings when the library exports are made (and results in the PR).

In the patch, I’ve left Darwin4-7 as is (corresponding to OS X 10.0-10.4) and 
work-
around in place for Darwin8 (since I’ve not been able to test the change with 
the
final xcode tools available there).

Fix confirmed on Darwin10, with current trunk (this has been bootstrapped many
times while sitting in my queue).

OK for trunk?


OK, thanks.

IIUC libc++ puts explicit visibility("hidden") attributes on
individual inline functions, but I don't know what their reason for
that is. It might not be a darwin-specific thing.




[PATCH,Darwin, config] Fix PR70694; don't force visibility on inlines for Darwin > 8

2018-08-24 Thread Iain Sandoe
At some point, with the toolchain components available to Darwin8, it was
preferable to force everything generated by headers to be hidden.
However, the work-around wasn’t limited and it has caused Darwin x86/x86_64
to have a blanket application of  "-fvisibility-inlines-hidden” ever since.

Since, in libstdc++, the visibilities are specified explicitly and the flag
causes code to be hidden that is intended to be visible.  This causes a lot of
warnings when the library exports are made (and results in the PR).

In the patch, I’ve left Darwin4-7 as is (corresponding to OS X 10.0-10.4) and 
work-
around in place for Darwin8 (since I’ve not been able to test the change with 
the
final xcode tools available there).

Fix confirmed on Darwin10, with current trunk (this has been bootstrapped many
times while sitting in my queue).

OK for trunk?
Iain

libstdc++/

PR libstdc++/70694
* configure.host (OPT_LDFLAGS): Don't append
-fvisibility-inlines-hidden for newer Darwin.
---
 libstdc++-v3/configure.host | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/libstdc++-v3/configure.host b/libstdc++-v3/configure.host
index caea9de9c7..155a3cdea1 100644
--- a/libstdc++-v3/configure.host
+++ b/libstdc++-v3/configure.host
@@ -230,16 +230,15 @@ case "${host_os}" in
 os_include_dir="os/newlib"
 OPT_LDFLAGS="${OPT_LDFLAGS} \$(lt_host_flags)"
 ;;
-  darwin | darwin[1-7] | darwin[1-7].*)
-# On Darwin, performance is improved if libstdc++ is single-module.
-# Up to at least 10.3.7, -flat_namespace is required for proper
-# treatment of coalesced symbols.
+  darwin[4-7] | darwin[4-7].*)
+# For earlier Darwin, performance is improved if libstdc++ is
+# single-module. Up to at least 10.3.7, -flat_namespace is required
+# for proper treatment of coalesced symbols.
 OPT_LDFLAGS="${OPT_LDFLAGS} -Wl,-single_module -Wl,-flat_namespace"
 os_include_dir="os/bsd/darwin"
 ;;
-  darwin[89] | darwin[89].* | darwin[1-9][0-9]* )
-# On Darwin, performance is improved if libstdc++ is single-module,
-# and on 8+ compatibility is better if not -flat_namespace.
+  darwin8 | darwin8.* )
+# For 8+ compatibility is better if not -flat_namespace.
 OPT_LDFLAGS="${OPT_LDFLAGS} -Wl,-single_module"
 case "${host_cpu}" in
   i[34567]86 | x86_64)
@@ -248,6 +247,10 @@ case "${host_os}" in
 esac
 os_include_dir="os/bsd/darwin"
 ;;
+  darwin*)
+# Post Darwin8, defaults should be sufficient.
+os_include_dir="os/bsd/darwin"
+;;
   *djgpp*)  # leading * picks up "msdosdjgpp"
 os_include_dir="os/djgpp"
 error_constants_dir="os/djgpp"
-- 
2.17.1