[MacPorts] #29345: PyMOL 1.4 fails to build with gcc 4.4 error

MacPorts noreply at macports.org
Mon May 2 17:32:46 PDT 2011


#29345: PyMOL 1.4 fails to build with gcc 4.4 error
------------------------------------------+---------------------------------
 Reporter:  michelle.lynn.gill@…          |       Owner:  macports-tickets@…                   
     Type:  defect                        |      Status:  new                                  
 Priority:  Normal                        |   Milestone:                                       
Component:  ports                         |     Version:  1.9.2                                
 Keywords:                                |        Port:  pymol                                
------------------------------------------+---------------------------------

Comment(by howarth@…):

 The problem is from the usage of -fno-common whenever the usage of "-arch
 x86_64 " is suppressed...

        -fno-common
            In C code, controls the placement of uninitialized global
 variables.  Unix C compilers have traditionally permitted multiple
 definitions of such variables in different compilation units by
            placing the variables in a common block.  This is the behavior
 specified by -fcommon, and is the default for GCC on most targets.  On the
 other hand, this behavior is not required by ISO C, and
            on some targets may carry a speed or code size penalty on
 variable references.  The -fno-common option specifies that the compiler
 should place uninitialized global variables in the data section
            of the object file, rather than generating them as common
 blocks.  This has the effect that if the same variable is declared
 (without "extern") in two different compilations, you will get a
            multiple-definition error when you link them.  In this case,
 you must compile with -fcommon instead.  Compiling with -fno-common is
 useful on targets for which it provides better performance, or
            if you wish to verify that the program will work on other
 systems which always treat uninitialized variable declarations this way.

 Simple fix is to append -fcommon to the end of the compile flags as it
 done in the attached Portfile.diff and revised setup_py.diff patch.

-- 
Ticket URL: <https://trac.macports.org/ticket/29345#comment:16>
MacPorts <http://www.macports.org/>
Ports system for Mac OS


More information about the macports-tickets mailing list