<p dir="ltr"><br>
> We are going this way, yes.</p>
<p dir="ltr">You've confused me a bit here ( maybe I was being too vague )</p>
<p dir="ltr">Okay so I understand thst the old LLVM specific archive format is now gone.</p>
<p dir="ltr">However it seems you are allowing LLVM bitcode files ( I assume that's what you mean by "IL" - does that stand for "intermediate language"? It's not in [1] ) to be placed inside the more standard archive format understood by GNU ar and nm.</p>

<p dir="ltr">Therefore LLVM is still supporting runtime libraries that consist of llvm bitcode files (even if the format is now different)</p>
<p dir="ltr">For example, I can build a runtime library (e.g. a simple C library) as a collection of bitcode modules and place them in an archive using the latest llvm-ar ( I realise that currently the archive's symbol table will be missing symbols from the bitcode files).</p>

<p dir="ltr">> I<br>
> posted what I think is the last big patch for review (making the<br>
> Mangler not depend on target). With that in things should move fairly<br>
> quickly to have llvm-ar just work with IL files and with that<br>
> lib/Object should have the features you need.</p>
<p dir="ltr">Okay. Could you please clarify? Do you mean?</p>
<p dir="ltr">- Future changes to lib/Object will let me read the symbols in an archive so I can implement my own ( primitive bitcode only ) linking?</p>
<p dir="ltr">Or</p>
<p dir="ltr">- Future changes to lib/Object will  implement llvm module linking for me?</p>
<p dir="ltr">I suspect you meant the first. If so, is the intention that if someone needs to link an in memory LLVM bitcode module to an archive of bitcode modules ( produced by the new llvm-ar or at with llvmLTO wrapper to ar) then they should use the API of lld? Does that API exist now? I took a look at the lld source code and I couldn't find any methods that returned llvm::Module so I assumed it wasn't possible.</p>

<p dir="ltr">Thanks,<br>
Dan Liew</p>