<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Courier; ">It is simpler. There is not any Mach-O envelope. The platform linker  </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Courier; ">can directly read Mach-O files as well as llvm bit-code file (using  </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Courier; ">llvm bit-code file reader).</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Courier; min-height: 16px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Courier; ">><i> Not sure if/where the exact form of the Mach-O file that carries bit  </i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Courier; ">><i> code is documented.</i></div></blockquote></div><div><br></div><div>Thanks for that.  Yes, I see what you mean (no Mach-O envelope), yet there seems to be something fundamentally different between a bit-code file I create from Apple's llvm-gcc-4.2, and one created from the LLVM APIs.</div><div>Particularly:</div><div>- ld won't consume the/a bit-code file that is directly generated by the LLVM APIs:  "ld warning: in foo.bc, file is not of required architecture"</div><div>- The bit-code file I have from LLVM differs from ones generated by Apple's llvm-gcc-4.2.  The latter has a "DE C0 17 0B" magic introducer, and there seems to be another 16 bytes before the "BC Code" (42 43 C0 DE) magic appears.</div><div>Whereas, the file generated from the LLVM APIs starts immediately with the "BC  Code" magic number.</div><div><br></div><div>There's a really good chance that this is just a case of 'user error'.  At the very least it seems to me that I'm not doing something that's required to emit bit-code files in the format that they are consumable by ld.  Alternatively, there is some kind of wrapper that the llvm-gcc-4.2 tool produces around the basic bit-code, though not as you've pointed out, a Mach-O format.</div><div><br></div><div>FWIW, here are the first 24 bytes, up to and including what I recognise as the LLVM bit-code magic number:</div><div>DE C0  17 0B  00 00  00 00  14 00  00 00  AC 01  00 00  07 00  00 00  <font class="Apple-style-span" color="#FF1E01">42 43  C0 DE</font>...</div><div><br></div><div>The 'file' util identifies this as "Compiled PSI (v1) data", though that's probably not relevant/useful, as it just comes from the DE C0, which could be any number of things.</div><div><br></div><div>Anyway, I guess my simple question is:</div><div>What do I need to do to get home-brew bit-code output from the LLVM bit-code writer to conform to whatever requirements that ld has for input?</div><div><br></div><div>-- lwe</div><div> </div><br></div></body></html>