<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 4, 2015, at 12:25 PM, Dan Liew <<a href="mailto:dan@su-root.co.uk" class="">dan@su-root.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Hi Chris,<br class=""><br class="">Thanks for working on this. I haven't been following LLVM for a few<br class="">months and in that time it seems support for building a monolithic<br class="">shared library has been added which is great! I've been looking over<br class="">it and I have a few questions/comments.<br class=""><br class="">* The LLVM_BUILD_LLVM_DYLIB flag isn't document. I've attached a patch for this.<br class=""></div></blockquote><div><br class=""></div>Patch LGTM. Later today I will also add this to my patches currently under review: <a href="http://reviews.llvm.org/D8046" class="">http://reviews.llvm.org/D8046</a></div><div><br class=""><blockquote type="cite" class=""><div class=""><br class="">* I'm not very familiar with export lists so sorry if this is a dumb<br class="">question. I see that one is generated that only has LLVM's C API in<br class="">it.<br class=""> It doesn't look like this file gets installed or used by the rest of<br class="">the build. Who is the intended consumer for this file?<br class=""></div></blockquote><div><br class=""></div><div>It is consumed by the linker. The linker then uses the export list to determine what symbols are exposed in the final binary.</div><br class=""><blockquote type="cite" class=""><div class=""><br class="">* I think there's a difference in behaviour between the<br class="">autoconf/Makefile build system's ``--enabled-shared``<br class=""> and the current implementation. When LLVM is built with<br class="">--enable-shared the llvm tools are linked against the shared<br class=""> library but with LLVM_BUILD_LLVM_DYLIB the tools are still linked<br class="">against the static LLVM libraries. I'm not sure<br class=""> if people really care about this (perhaps distribution package<br class="">maintainers might?).<br class=""></div></blockquote><div><br class=""></div><div>You’re the first person to mention this. If it is a problem it can be addressed, although it will need to be controlled by flags. Linking the tools against the dylib would mean exporting the C++ API not just the C API, and validating that the dylib is configured to contain all the libraries required by the tool.</div><div><br class=""></div><div>Unlike the Makefile build system the CMake build system’s dylib is highly configurable to fit with the needs of embedded clients.</div><br class=""><blockquote type="cite" class=""><div class=""><br class="">* The exported LLVM targets [1] which external projects using CMake can use<br class=""> to add LLVM to their project still refers to LLVM's static<br class="">libraries rather than the built<br class=""> dynamic library. Should this be changed? I'm not sure how easy this would be.<br class=""></div></blockquote><div><br class=""></div><div>The CMake build system’s dylib is highly configurable, so I don’t think this should change.</div><br class=""><blockquote type="cite" class=""><div class=""><br class="">* Placing the files for building the shared library in ``tools/``<br class="">feels a bit odd given that its<br class=""> not actually a tool. Is there a good reason for doing this?<br class=""></div></blockquote><div><br class=""></div><div>I actually don’t know the history of this. llvm-shlib has been in tools before the CMake build system had support for it.</div><div><br class=""></div><div>-Chris</div><br class=""><blockquote type="cite" class=""><div class=""><br class="">[1] <a href="http://llvm.org/docs/CMake.html#embedding-llvm-in-your-project" class="">http://llvm.org/docs/CMake.html#embedding-llvm-in-your-project</a><br class=""><br class="">Thanks,<br class="">Dan.<br class=""><span id="cid:3E6B99F6-100F-4554-A3F1-4F755068C371"><document_LLVM_BUILD_DYLIB.patch></span></div></blockquote></div><br class=""></body></html>