Ned Deily added the comment:

This checkin also breaks OS X framework builds.  For some reason, framework 
builds are compiled with the gcc -fno-common option.  The code in configure.ac 
to add that option dates back to the initial OS X framework support 
(c3c87ce4afdc from 2001).  It's not clear to me why we use that option just in 
the case of framework builds (I suspect it may no longer be necessary) but the 
fact is that we have been and currently still do.  And, in any case, the GCC 
description of -fno-common 
(https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html) suggests that there 
may be valid reasons to use it on some platforms or that other compilers might 
behave this way by default.  A simple way to produce the error on Linux is:

./configure OPT="-fno-common" && make

[...]
gcc -pthread   -o Programs/_freeze_importlib Programs/_freeze_importlib.o 
Modules/getbuildinfo.o Parser/acceler.o Parser/grammar1.o Parser/listnode.o 
Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o 
Parser/firstsets.o Parser/grammar.o Parser/pgen.o Parser/myreadline.o 
Parser/parsetok.o Parser/tokenizer.o Objects/abstract.o Objects/accu.o 
Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o 
Objects/bytesobject.o Objects/cellobject.o Objects/classobject.o 
Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o 
Objects/enumobject.o Objects/exceptions.o Objects/genobject.o 
Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o 
Objects/funcobject.o Objects/iterobject.o Objects/listobject.o 
Objects/longobject.o Objects/dictobject.o Objects/memoryobject.o 
Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o 
Objects/object.o Objects/obmalloc.o Objects/capsule.o Objects/rangeobject.o 
Objects/setobject.o Objects/sliceo
 bject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o 
Objects/unicodeobject.o Objects/unicodectype.o Objects/weakrefobject.o 
Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o 
Python/bltinmodule.o Python/ceval.o Python/compile.o Python/codecs.o 
Python/dynamic_annotations.o Python/errors.o Python/frozenmain.o 
Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o 
Python/getplatform.o Python/getversion.o Python/graminit.o Python/import.o 
Python/importdl.o Python/marshal.o Python/modsupport.o Python/mystrtoul.o 
Python/mysnprintf.o Python/peephole.o Python/pyarena.o Python/pyctype.o 
Python/pyfpe.o Python/pyhash.o Python/pylifecycle.o Python/pymath.o 
Python/pystate.o Python/pythonrun.o Python/pytime.o Python/random.o 
Python/structmember.o Python/symtable.o Python/sysmodule.o Python/traceback.o 
Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/pystrhex.o 
Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/dynload
 _shlib.o   Python/thread.o Modules/config.o Modules/getpath.o Modules/main.o 
Modules/gcmodule.o  Modules/_threadmodule.o  Modules/signalmodule.o  
Modules/posixmodule.o  Modules/errnomodule.o  Modules/pwdmodule.o  
Modules/_sre.o  Modules/_codecsmodule.o  Modules/_weakref.o  
Modules/_functoolsmodule.o  Modules/_operator.o  Modules/_collectionsmodule.o  
Modules/itertoolsmodule.o  Modules/atexitmodule.o  Modules/_stat.o  
Modules/timemodule.o  Modules/_localemodule.o  Modules/_iomodule.o 
Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o 
Modules/textio.o Modules/stringio.o  Modules/zipimport.o  
Modules/faulthandler.o  Modules/_tracemalloc.o Modules/hashtable.o  
Modules/symtablemodule.o  Modules/xxsubtype.o -lpthread -ldl  -lutil   -lm
Python/pylifecycle.o:(.bss+0x20): multiple definition of `Py_FrozenFlag'
Programs/_freeze_importlib.o:(.data+0x0): first defined here
collect2: error: ld returned 1 exit status
Makefile:710: recipe for target 'Programs/_freeze_importlib' failed
make: *** [Programs/_freeze_importlib] Error 1

The OS X version of ld helpfully lists the modules:

duplicate symbol _Py_FrozenFlag in:
    Programs/_freeze_importlib.o
    Python/pylifecycle.o

I'm also not sure why the Py_FrozenFlag definition was added to 
_freeze_importlib.c in the first place.  Reverting it with the following patch 
seems to solve the problem in the few configurations I tried (OS X framework, 
OS X non-shared, Linux non-shared, Linux shared).

diff Programs/_freeze_importlib.c
--- a/Programs/_freeze_importlib.c      Tue May 05 12:04:35 2015 -0700
+++ b/Programs/_freeze_importlib.c      Tue May 05 17:10:39 2015 -0700
@@ -12,8 +12,6 @@
 #include <unistd.h>
 #endif

-int Py_FrozenFlag = 1;  /* Suppress errors from getpath.c */
-
 /* To avoid a circular dependency on frozen.o, we create our own structure
    of frozen modules instead, left deliberately blank so as to avoid
    unintentional import of a stale version of _frozen_importlib. */

----------
nosy: +ned.deily
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23911>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to