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

Message ID 1DA3D524-BFC7-413E-A78F-CE6D3E69C92D@sandoe.co.uk
State New
Headers show
Series
  • [Darwin,config] Fix PR70694; don't force visibility on inlines for Darwin > 8
Related show

Commit Message

Iain Sandoe Aug. 24, 2018, 3:09 p.m.
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(-)

-- 
2.17.1

Comments

Jonathan Wakely Aug. 24, 2018, 3:47 p.m. | #1
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

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"