classification
Title: Remove -fno-common compile option from OS X framework builds?
Type: compile error Stage: resolved
Components: Build, macOS Versions: Python 3.5
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: ned.deily Nosy List: ned.deily, ronaldoussoren
Priority: normal Keywords:

Created on 2015-05-06 01:21 by ned.deily, last changed 2020-10-19 19:15 by ronaldoussoren. This issue is now closed.

Messages (4)
msg242636 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2015-05-06 01:21
As noted in msg242635 of issue23911, for some reason configure.ac adds the gcc -fno-common option for OS X framework builds.  Is this still necessary?  I'm guessing it might be vestigial code left over from the Mac toolbox support in Python 2 that was removed in Python 3.

diff configure.ac
--- a/configure.ac      Tue May 05 12:04:35 2015 -0700
+++ b/configure.ac      Tue May 05 16:47:34 2015 -0700
@@ -2101,9 +2101,6 @@
 AC_MSG_CHECKING(for --enable-framework)
 if test "$enable_framework"
 then
-       BASECFLAGS="$BASECFLAGS -fno-common -dynamic"
-       # -F. is needed to allow linking to the framework while
-       # in the build location.
        AC_DEFINE(WITH_NEXT_FRAMEWORK, 1,
          [Define if you want to produce an OpenStep/Rhapsody framework
          (shared library plus accessory files).])

Also, there seems to be a unused reference to $extra_undefs left over in configure.ac from the removed Mac toolbox support:

--- a/configure.ac      Tue May 05 12:04:35 2015 -0700
+++ b/configure.ac      Tue May 05 18:20:21 2015 -0700
@@ -2346,8 +2346,6 @@
        Linux*|GNU*) LINKFORSHARED="-Xlinker -export-dynamic";;
        # -u libsys_s pulls in all symbols in libsys
        Darwin/*)
-               LINKFORSHARED="$extra_undefs -framework CoreFoundation"
-
                # Issue #18075: the default maximum stack size (8MBytes) is too
                # small for the default recursion limit. Increase the stack size
                # to ensure that tests don't crash
msg242637 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2015-05-06 01:24
Sorry, that second patch should have been:

diff -configure.ac
--- a/configure.ac      Tue May 05 12:04:35 2015 -0700
+++ b/configure.ac      Tue May 05 18:22:39 2015 -0700
@@ -2346,7 +2346,7 @@
        Linux*|GNU*) LINKFORSHARED="-Xlinker -export-dynamic";;
        # -u libsys_s pulls in all symbols in libsys
        Darwin/*)
-               LINKFORSHARED="$extra_undefs -framework CoreFoundation"
+               LINKFORSHARED="-framework CoreFoundation"

                # Issue #18075: the default maximum stack size (8MBytes) is too
                # small for the default recursion limit. Increase the stack size
msg243259 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2015-05-15 09:08
According to [1] common symbols are not allowed in frameworks. I guess that's why we added '-fno-common' to the linker flags. 

[1] https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkBinding.html#//apple_ref/doc/uid/20002256-BAJICBDD
msg378990 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2020-10-19 19:15
I've checked and '-fcommon' is default (at least with Xcode 12 beta on x86_64), and likely not what you'd want:  With "-fcommon" the definition a non-static variable in two different files will get merged:

first.m:   int x;
second.m:   int x;

Without '-fno-common' this will be allowed (and that's generally not what you want, correct usage is to have one of the files use "extern int x;".  In clang 11 "-fno-common" is enabled by default, but I don't know when Apple do this in their copy of clang.

----


I'm closing this issue because using -fno-common is necessary avoid having a common section in the framework (see msg243259)
History
Date User Action Args
2020-10-19 19:15:55ronaldoussorensetstatus: open -> closed
type: compile error
messages: + msg378990

resolution: not a bug
stage: patch review -> resolved
2015-05-15 09:08:35ronaldoussorensetmessages: + msg243259
2015-05-06 01:24:38ned.deilysetmessages: + msg242637
2015-05-06 01:21:27ned.deilycreate