Great info @bwilson. Thank you.
> If you want to do that, search for the "__LLVM" segment
Ahh, you're correct. When I searched for the __LLVM segment, I do see that the assembly's .o file contains an __LLVM segment.
> Assembly source files should work in the sense that you can build and run your project. I did not mean to imply that we somehow de-compile the assembly source into bitcode.
When it becomes a requirement to submit apps in bitcode format, how will this impact architecture specific code (ie. assembly, or anything that is ifdef'd for that matter). It makes sense that assembly isn't converted to bitcode, but doesn't everything need to be in bitcode in order for an archive to be fully encoded in bitcode? I have an app that's hitting a compile warning when archiving complaining that a specific 3rd party library doesn't contain bitcode so the app cannot be archived with bitcode. That 3rd party library won't emit bitcode ostensibly because it contains assembly (I could be wong about the cause, though).
> The actual bitcode content is included when you do an Archive build.
Does bitcode content get included when static libraries are built? Dynamic libraries? If not, how should 3rd party library vendors distribute their libraries such that app developers can include them and then spit out bitcode in an archive?
> You should be aware that a normal build with the -fembed-bitcode-marker option will produce minimal size embedded bitcode sections without any real content.
Hmm, that's interesting. I didn't come up with that option myself, that's what Xcode showed in the build logs when I build a static library with bitcode turned on. I would have thought it would contain "real content", otherwise how will 3rd party libraries get distributed to apps?
Thanks again for your responses. This is a really big change to the way things work and the documentation is quite sparse at the moment. I really appreciate the help here!