[GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P`

[GHC]

#11744: Latest Xcode update violates POSIX compliance of `nm -P`
----------------------------------------+---------------------------------
           Reporter:  hvr               |             Owner:
               Type:  bug               |            Status:  new
           Priority:  normal            |         Milestone:
          Component:  Build System      |           Version:
           Keywords:                    |  Operating System:  MacOS X
       Architecture:  Unknown/Multiple  |   Type of failure:  None/Unknown
          Test Case:                    |        Blocked By:
           Blocking:                    |   Related Tickets:
Differential Rev(s):                    |         Wiki Page:
----------------------------------------+---------------------------------
 TLDR: Apple messed up again and broke POSIX compliance


 luite ran into problems when he installed the latest Xcode update because
 the derived platform constants were off.

 He provided me the output of `nm -P ./includes/dist-
 derivedconstants/header/tmp.o` which turned out have numbers which didn't
 make sense:

 {{{
 _derivedConstantAP_STACK_SPLIM C 1025 0
 _derivedConstantBITMAP_BITS_SHIFT C 7 0
 _derivedConstantBLOCKS_PER_MBLOCK C 253 0
 _derivedConstantBLOCK_SIZE C 4097 0
 _derivedConstantCINT_SIZE C 5 0
 _derivedConstantCLONG_LONG_SIZE C 9 0
 _derivedConstantCLONG_SIZE C 9 0
 _derivedConstantDOUBLE_SIZE C 9 0
 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0
 ...
 }}}

 Which with an older Xcode version would have looked like

 {{{
 _derivedConstantAP_STACK_SPLIM C 401 0
 _derivedConstantBITMAP_BITS_SHIFT C 7 0
 _derivedConstantBLOCKS_PER_MBLOCK C fd 0
 _derivedConstantBLOCK_SIZE C 1001 0
 _derivedConstantCINT_SIZE C 5 0
 _derivedConstantCLONG_LONG_SIZE C 9 0
 _derivedConstantCLONG_SIZE C 9 0
 _derivedConstantDOUBLE_SIZE C 9 0
 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0
 ...
 }}}

 So obviously `nm -P`'s output changed from hexadecimal to (non-compliant)
 decimal formatting of numbers.

 For reference, here's how POSIX specifies the semantics of `nm`:

 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/nm.html

 > `-P`
 >    Write information in a portable output format, as specified in the
 STDOUT section.

 ...

 > If the `-P` option is specified, the previous information shall be
 displayed using the following portable format. The three versions differ
 depending on whether `-t d`, `-t o`, or `-t x` was specified,
 respectively:
 >
 > {{{"%s%s %s %d %d\n", <library/object name>, <name>, <type>, <value>,
 <size>}}}
 >
 > {{{"%s%s %s %o %o\n", <library/object name>, <name>, <type>, <value>,
 <size>}}}
 >
 > {{{"%s%s %s %x %x\n", <library/object name>, <name>, <type>, <value>,
 <size>}}}


 In the event that Apple can't be bothered to fix this bug (I've had bad
 experience with Apple and standard-compliance in the past, hence my
 pessimism) we could try to workaround by using `nm -P -t x` when building
 on OSX...

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11744>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler