[GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P`
#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",
, <name>, <type>, <value>, <size>}}} {{{"%s%s %s %o %o\n",
, <name>, <type>, <value>, <size>}}} {{{"%s%s %s %x %x\n",
, <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
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | 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: | ---------------------------------+---------------------------------------- Description changed by hvr: @@ -8,2 +8,2 @@ - derivedconstants/header/tmp.o` which turned out have numbers which didn't - make sense: + derivedconstants/header/tmp.o` which turned out to have numbers which + didn't make sense: @@ -46,0 +46,2 @@ + ---- + @@ -66,0 +68,7 @@ + ... + + > '''If `-P` is specified, but `-t` is not, the format shall be as if `-t + x` had been specified.''' + + ---- + New description: 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 to 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",
, <name>, <type>, <value>, <size>}}} {{{"%s%s %s %o %o\n",
, <name>, <type>, <value>, <size>}}} {{{"%s%s %s %x %x\n",
, <name>, <type>, <value>, <size>}}}
...
'''If `-P` is specified, but `-t` is not, the format shall be as if `-t x` had been specified.'''
---- 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#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | 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: | ---------------------------------+---------------------------------------- Comment (by luite): thanks for creating the ticket. Unfortunately the new nm doesn't support the `-t x` option: {{{ luite@Luites-MacBook-Pro:~/haskell/build/ghc-8.0.0.20160322/includes/dist- derivedconstants/header$ nm -P -t x tmp.o nm: Unknown command line argument '-t'. Try: '/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm -help' nm: Did you mean '-A'? luite@Luites-MacBook-Pro:~/haskell/build/ghc-8.0.0.20160322/includes/dist- derivedconstants/header$ nm -P -tx tmp.o nm: Unknown command line argument '-tx'. Try: '/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm -help' nm: Did you mean '-x'? }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | 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: | ---------------------------------+---------------------------------------- Comment (by carter): what version of OS X, XCODE (and thus puttatively GHC) are impacted? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | 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: | ---------------------------------+---------------------------------------- Description changed by hvr: @@ -80,0 +80,13 @@ + + ---- + + Alternative workaround (since it turns out that Apple's `nm` violates + POSIX even more than assumed by not even supporting `nm -P -t x`): + + Have `deriveConstants` derive a known value, e.g. the value `0x1234` via + `char derivedConstantCONTROL_GROUP[1+0x1234];`, and if the value for + `CONTROL_GROUP` comes back as `18016` we know that we need to fixup all + decimal-wrongly-as-hex parsed integers, if it comes back as `4660` we + parsed correctly; any different value is a non-recoverable error + + This would also serve as a general integrity check for //all// platforms New description: 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 to 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",
, <name>, <type>, <value>, <size>}}} {{{"%s%s %s %o %o\n",
, <name>, <type>, <value>, <size>}}} {{{"%s%s %s %x %x\n",
, <name>, <type>, <value>, <size>}}}
...
'''If `-P` is specified, but `-t` is not, the format shall be as if `-t x` had been specified.'''
---- 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... ---- Alternative workaround (since it turns out that Apple's `nm` violates POSIX even more than assumed by not even supporting `nm -P -t x`): Have `deriveConstants` derive a known value, e.g. the value `0x1234` via `char derivedConstantCONTROL_GROUP[1+0x1234];`, and if the value for `CONTROL_GROUP` comes back as `18016` we know that we need to fixup all decimal-wrongly-as-hex parsed integers, if it comes back as `4660` we parsed correctly; any different value is a non-recoverable error This would also serve as a general integrity check for //all// platforms -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | 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: | ---------------------------------+---------------------------------------- Comment (by carter): it looks like the new version of nm is llvm-nm, or at least a snapshot thereof http://llvm.org/docs/CommandGuide/llvm-nm.html -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | 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: | ---------------------------------+---------------------------------------- Comment (by carter): heres a listing of the new apple nm flag options/output, for comparision with the prior one {{{ $ /Users/carter/Desktop/bad-cli-tools/Command\ Line\ Tools\ \(OS\ X\ 10.11\)/CLTools_Executables.pkg.cpio.xz/Library/Developer/CommandLineTools/usr/bin/nm --help OVERVIEW: llvm symbol table dumper USAGE: nm [options] <input files> --s Dump only symbols from this segment and section name, Mach-O only OPTIONS: General options: -B - Alias for --format=bsd -P - Alias for --format=posix -aarch64-neon-syntax - Choose style of NEON code to emit from AArch64 backend: =generic - Emit generic NEON assembly =apple - Emit Apple-style NEON assembly -arch=<string> - architecture(s) from a Mach-O file to dump -debug-syms - Show all symbols, even debugger only -defined-only - Show only defined symbols -dynamic - Display the dynamic symbols instead of normal symbols. -enable-objc-arc-opts - enable/disable all ARC Optimizations -enable-scoped-noalias - -enable-tbaa - -extern-only - Show only external symbols -format - Specify output format =bsd - BSD format =sysv - System V format =posix - POSIX.2 format =darwin - Darwin -m format -join-liveintervals - Coalesce copies (default=true) -just-symbol-name - Print just the symbol's name -m - Alias for --format=darwin -no-llvm-bc - Disable LLVM bitcode reader -no-sort - Show symbols in order encountered -numeric-sort - Sort symbols by address -print-after-all - Print IR after each pass -print-armap - Print the archive map -print-before-all - Print IR before each pass -print-file-name - Precede each symbol with the object file it came from -print-size - Show symbol size instead of address -reverse-sort - Sort in reverse order -rng-seed=<seed> - Seed for the random number generator -s=<string> - Dump only symbols from this segment and section name, Mach-O only -size-sort - Sort symbols by size -stackmap-version=<int> - Specify the stackmap encoding version (default = 1) -time-passes - Time each pass, printing elapsed time for each on exit -undefined-only - Show only undefined symbols -verify-dom-info - Verify dominator info (time consuming) -verify-loop-info - Verify loop info (time consuming) -verify-scev - Verify ScalarEvolution's backedge taken counts (slow) -x - Print symbol entry in hex, Mach-O only -x86-asm-syntax - Choose style of code to emit from X86 backend: =att - Emit AT&T-style assembly =intel - Emit Intel-style assembly Generic Options: -help - Display available options (-help-hidden for more) -help-list - Display list of available options (-help-list- hidden for more) -version - Display the version of this program }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | 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: | ---------------------------------+---------------------------------------- Comment (by hvr): I was told there might be a `nm-classic(1)` tool provided by Xcode 7.3; can somebody verify if it's there, and if we can pass that one to `./configure --with-nm=...` to workaround this issue temporarily? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | 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: | ---------------------------------+---------------------------------------- Comment (by chak): Did anybody file a Radar (Apple bug tracker) about this? (Otherwise, it is rather unlikely to be fixed.) Or maybe this should be reported to the LLVM folks? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | 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: | ---------------------------------+---------------------------------------- Comment (by carter): @chak I don't think either has be filed yet. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | 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: | ---------------------------------+---------------------------------------- Comment (by chak): After some talk on the mailing list, there is a simple enough workaround. Just use `nm-classic`. Specifically, check whether `xcode-select -p`/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic or `xcode-select -p`/usr/bin/nm-classic exists. If yes, use that instead of ’nm’; otherwise, use ’nm’ as usual. (You need to check for both, because the former is what comes with Xcode and the latter is what comes with the standalone command line tool package.) Printing decimal numbers instead of hex with the '-P' option still looks like an oversight, but I think that would need to be taken up with the LLVM maintainers, instead of trying to route through Apple (who are probably just going to point to 'nm-classic' anyway). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | 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: | ---------------------------------+---------------------------------------- Comment (by bgamari): Someone should really bring this up with the Apple folks. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: Resolution: | 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: | ---------------------------------+---------------------------------------- Changes (by gridaphobe): * priority: normal => highest Comment: I'm bumping the priority on this since it blocks building GHC with XCode 7.3 (see #11823). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2113 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by hvr): * differential: => phab:D2113 Comment: See phab:D2113 for a early idea expressed as a patch I put up for discussion -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P`
---------------------------------+----------------------------------------
Reporter: hvr | Owner:
Type: bug | Status: new
Priority: highest | Milestone:
Component: Build System | Version:
Resolution: | Keywords:
Operating System: MacOS X | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s): phab:D2113
Wiki Page: |
---------------------------------+----------------------------------------
Comment (by Ben Gamari
#11744: Latest Xcode update violates POSIX compliance of `nm -P`
---------------------------------+----------------------------------------
Reporter: hvr | Owner:
Type: bug | Status: new
Priority: highest | Milestone:
Component: Build System | Version:
Resolution: | Keywords:
Operating System: MacOS X | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s): phab:D2113
Wiki Page: |
---------------------------------+----------------------------------------
Comment (by Ben Gamari
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2113 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by ilovezfs): Unsurprisingly, especially since the bug is in the upstream LLVM code, it's not fixed in 7.3.1. However, this may be a relatively simple workaround until it's fixed. On OS X, these all appear to have the same output: With Xcode >= 7.3, {{{ nm $k | awk '{ print $NF" "$2" "$1" 0" }' llvm-nm $k | awk '{ print $NF" "$2" "$1" 0" }' nm-classic $k | awk '{ print $NF" "$2" "$1" 0" }' nm-classic -P $k }}} With Xcode < 7.3, {{{ nm $k | awk '{ print $NF" "$2" "$1" 0" }' nm -P $k }}} So {{{ if darwin, `nm $k | awk '{ print $NF" "$2" "$1" 0" }'` else `nm -P` }}} should give the same output regardless of platform or Xcode version. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2113 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by ilovezfs): FYI upstream LLVM has now fixed this bug: https://github.com/llvm- mirror/llvm/commit/ae7cf58516cc4824e32187285dc524188afb750c So hopefully it will make its way over to Xcode soon. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+-------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2113 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by George): * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+-------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2113 Wiki Page: | ---------------------------------+-------------------------------------- Comment (by goldfire): Ping. I'm still saying `--with-nm=nm-classic` (for the `nm-classic` I have in my PATH) whenever I need to build GHC. Is this still the recommended action? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+-------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2113 Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): It actually appears that the latest XCode release (8.1) fixes this. It shouldn't be necessary to use `nm-classic` with, {{{ $ nm --version Apple LLVM version 8.0.0 (clang-800.0.38) Optimized build. Default target: x86_64-apple-darwin16.0.0 Host CPU: haswell }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+-------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2113 Wiki Page: | ---------------------------------+-------------------------------------- Comment (by goldfire): So should this ticket be closed then? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+-------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: highest | Milestone: Component: Build System | Version: Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2113 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Why yes, I suppose it should be. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11744#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC