search for: writearchive

...ad of as a frontend for llvm-ar. (llvm-ranlib is an example of a frontend for llvm-ar, where it's the same underlying binary which just does different option parsing depending on how it's invoked.) Much of the archive writing logic that llvm-ar uses is already factored out to libObject (the writeArchive function), and we can factor more of it out as needed, so we shouldn't end up with too much duplicated code between llvm-ar and llvm-libtool. At the same time, making llvm-libtool its own tool gives us the freedom to e.g. factor out parts of llvm-lipo into a library to handle universal inputs a...

...r in existence, actually useful (linkers can use it's .a files) and far easier to maintain. When the effort to support windows came up, there was a need to create archives from within lld since link.exe can run lib.exe. The maintainable code was easy to refactor into one library function llvm::writeArchive. If another use ever show up, we evaluate it. If not, we keep the very narrow interface. > Finally, I will directly state that we (Google) have a specific interest in > both linking LLD libraries into the Clang executable rather than having > separate binaries, and in invoking LLD to link...

...hard > to write good library code, as you say: > > >> When the effort to support windows came up, there was a need to create >> archives from within lld since link.exe can run lib.exe. The >> maintainable code was easy to refactor into one library function >> llvm::writeArchive. If another use ever show up, we evaluate it. If >> not, we keep the very narrow interface. >> > > Yes, +1 to narrow interface, but I think it should always be *in a > library*. That impacts much more than just the interface. > > >> >> > Finally, I will dir...

...y: >>> >>> >>>> When the effort to support windows came up, there was a need to create >>>> archives from within lld since link.exe can run lib.exe. The >>>> maintainable code was easy to refactor into one library function >>>> llvm::writeArchive. If another use ever show up, we evaluate it. If >>>> not, we keep the very narrow interface. >>>> >>> >>> Yes, +1 to narrow interface, but I think it should always be *in a >>> library*. That impacts much more than just the interface. >>>...

Sorry for being late on this thread. I just wanted to say I am strongly on Rui's side on this one. There current design is for lld *not* not be a library and I think that is important. That has saved us a tremendous amount of work for doing library like code and a lot of design for library interfaces. The comparison of old and new ELF code is night and day as far as productivity and

Hi, Using master at b0a1c0b72c9c61f8b0a223e08f43498abb64f5e8, I cannot build LLVM. I configured with: CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=$HOME/opt/llvm11-git \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_BUILD_LLVM_DYLIB=ON \ -DLLVM_LINK_LLVM_DYLIB=ON \ -DBUILD_SHARED_LIBS=OFF \ -DLLVM_ENABLE_EH=ON \ -DLLVM_ENABLE_RTTI=ON \