by rustf3:

What steps will reproduce the problem?
   > go build hello  (hello world will do)
   > otool -l hello | grep LC_  (compare this output with valid output below)
      cmd LC_SEGMENT_64
      cmd LC_SEGMENT_64
      cmd LC_SEGMENT_64
      cmd LC_SEGMENT_64
      cmd LC_SEGMENT_64
      cmd LC_UNIXTHREAD
      cmd LC_SYMTAB
      cmd LC_DYSYMTAB
      cmd LC_LOAD_DYLINKER

The OSX executable produced is fine except that it will be rejected if submitted to the
Mac App Store.  The error that comes back after submitting the app is:

    "Missing DWARF data - Your app does not include DWARF data with architecture information in
     Contents/MacOS/Bampf . In your Xcode build settings, ensure that the debug information is set
     to "DWARF with dSYM" and that the list of valid architectures does not include PPC." 

What is the expected output?
    A workaround is to use the external linker as follows:
   > go build -ldflags "-linkmode=external" hello.go 
   > otool -l hello | grep LC_
      cmd LC_SEGMENT_64
      cmd LC_SEGMENT_64
      cmd LC_SEGMENT_64
      cmd LC_SEGMENT_64
      cmd LC_DYLD_INFO_ONLY
      cmd LC_SYMTAB
      cmd LC_DYSYMTAB
      cmd LC_LOAD_DYLINKER
      cmd LC_UUID                               <-- needed for Mac App Store?
      cmd LC_VERSION_MIN_MACOSX
      cmd LC_SOURCE_VERSION
      cmd LC_MAIN
      cmd LC_LOAD_DYLIB
      cmd LC_FUNCTION_STARTS
      cmd LC_DATA_IN_CODE
      cmd LC_DYLIB_CODE_SIGN_DRS

What do you see instead?
   The golang internal linker produces OSX executables that can be packaged signed, and self distributed.  Ideally it would also produce OSX executables that could be submitted to the App store by creating output similar to the native OSX gcc/ld.

Which compiler are you using (5g, 6g, 8g, gccgo)?
  6g

Which operating system are you using?
  OS X 10.8.4 (12E55)

Which version are you using?  (run 'go version')
   go version go1.1.2 darwin/amd64 (also happens with go1.1.1)

Please provide any additional information below.
   This problem appears similar in nature to https://golang.org/issue/5238 where the external linker was used to produce system specific fields in the binary.