Tomas Lindquist Olsen Wrote: > > This locks D to the LLVM backend, things like that is never a good idea. >
you could say the same thing about .net and Java - Java locks you to .class files and .net locks you to assemblies. there are many JVMs from different vendors for different platforms which are interoperable because of this. IIRC Mono can work with MS assemblies and also there's the interoperability between different .net languages. > Also, LLVM bitcode files produced both by LDC and Clang/llvm-gcc are > platform specific. Sure you can process them on any platform, but the > source code they were compiled from was platform specific, and so is > the resulting bitcode. Using LLVM bitcode as a replacement format for > native OMF/COFF/ELF objects, does not give us platform neutrality. > I don't know llvm that well but it seems that for clang/llvm-gcc the reason for this is because of the source language (c/c++) which is platform specific. Can you elaborate about this for LDC? where are the problematic parts and what can be done to make the output platform-neutral? I read that platform specific things like sizeof where hardcoded in the resulting bit-code but now they replaced it with a sizeof intrinsic so that the resulting bit-code would not depend on this. are there any other problematic cases like this still remaining? > -Tomas
