Date: Wed, 25 Jul 2012 10:48:27 +0100 From: David Chisnall <theraven@theravensnest.org> To: Luba Tang <lubatang@gmail.com> Cc: freebsd-toolchain@freebsd.org Subject: Re: MCLinker and llvm-config Message-ID: <0FD17AD0-AD5B-4B06-A966-849699AA4A1D@theravensnest.org> In-Reply-To: <CAMW0cx=hw=OaJVOHWQKkbgzJq1XNbMn5KjDYKEVkp-tffFqNFw@mail.gmail.com> References: <CAMW0cx=hw=OaJVOHWQKkbgzJq1XNbMn5KjDYKEVkp-tffFqNFw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25 Jul 2012, at 10:22, Luba Tang wrote: > Let me explain the status of MCLinker. > MCLinker now is one of the standard system linkers in Android system. > https://android.googlesource.com/platform/frameworks/compile/mclinker It looks like MCLinker has made a lot of progress since I last checked.=20= > Since there are many practical issues in ELF system (some of them are > undocumented :'( ), I think MCLinker could be said as a linker who is > robust enough to handle with wrapped symbols, segments, .group = section, > exception, DWRAF, and many many ELF unique features. :) Indeed. How do you plan on integrating modern features like LTO into = MCLinker? Can you deal with an atom-based model for efficient code = locality? > In our plan, we will get rid of LLVM in this September. At that time, > MCLinker wil be able to handle archives, and has some basic support = for > link script. What does 'get rid of LLVM' mean in this context? > We have promised BSD systems have higher priority than Linux systems, = and > we will keep our promise. That's also great. The FreeBSD Foundation has some funding set aside = for linker work, but currently nothing concrete to spend it on, so I'd = strongly invite people to submit project proposals in this area. > BTW, I think llvm-config is necessary for every LLVM-based project. If = it > will not be in BSD system, I think we can negotiate an approach to get = rid > of it. > Just like what Android did. I think the rationale for not having it in the base system is sensible: = we don't want things from outside the base system to link against the = LLVM from the base system. When other things are imported, we will most = likely replace their own build system (as we do with LLVM itself) and so = can hard code the location of the LLVM that they link against. David=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0FD17AD0-AD5B-4B06-A966-849699AA4A1D>