#45251: request for lldb --------------------------+---------------------- Reporter: rjvbertin@… | Owner: larryv@… Type: request | Status: assigned Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: lldb | --------------------------+---------------------- Comment (by rjvbertin@…): [this inadvertently went out as an email first, sorry about that]
I'm ok with splitting up the port and would be happy do to so if we can avoid build time regressions and setup sane dependencies.
Building a redistributable, standalone libclang is a bit of a separate issue, no? That said, it's also supposed to speed up compile times when using clang, as there are less shared libraries to load at each invocation.
I don't like the current situation in which clang rebuilds libLLVM.dylib at build time instead of using llvm-config to find the installed one to build and link against.
No, I agree (all the more since build times for 3.9 appear to be almost 50% longer than the ones for 3.8). That said, I tried my trick of calling make in the tools/clang. For once it doesn't work, probably because there are apparently 3 parallel directories that have to be built in the right order. You probably saw my thread about standalone building of lldb. In short: it almost works. I copied the missing CheckAtomic.cmake file into the installed cmake/llvm directory, and tried to build lldb. It aborted because of trying to include a headerfile from the llvm source: {{{ In file included from /opt/local/var/macports/build/_opt_local_site- ports_lang_llvm-3.9/lldb-3.9/work/llvm-3.9.0.src/tools/lldb/tools/lldb- mi/MICmdCmdData.cpp:45: /opt/local/var/macports/build/_opt_local_site- ports_lang_llvm-3.9/lldb-3.9/work/llvm-3.9.0.src/tools/lldb/tools/lldb- mi/MIUtilParse.h:13:10: fatal error: '../lib/Support/regex_impl.h' file not found #include "../lib/Support/regex_impl.h" ^ 1 error generated. }}} But, the extrapolated build time would be around 45 minutes (against IIRC almost 1h15 for my current approach) and the extrapolated build directory size is over 2x smaller.
If that is needed, it should be addressed as a patch to the build system that can be integrated upstream. Using install_name_tool can introduce a dependency on cctools, which is a pain point as it can cause a dependncy
Can you explain? Why would that the be case as long as we don't tell the port to use the copy from cctools?
Let's track that in a separate bug (I filed #52196). I'm of the opinion that `llvm-config --ldflags` should "do the right thing" but it doesn't setup rpath.
I've thought about this a bit more, and it may be a moot point. The official Linux builds I have on my Ubuntu rig also install libclang, libLLVM etc. somewhere that's not part of the standard ldconfig search path. IOW, cross-platform code already has to add the path to those libraries to its rpath, which should solve the issue on OS X too. No? -- Ticket URL: <https://trac.macports.org/ticket/45251#comment:28> MacPorts <https://www.macports.org/> Ports system for macOS