similar to: [LLVMdev] Should llvm include a linker?

It's not clear to me that this is worthwhile. Right now LLVM has no linker dependency, so there's no pressing reason to want to fold LLD into LLVM to solve a circular dependency. LLD can just depend on LLVM to get LTO working. On Thu, Jan 29, 2015 at 10:01 AM, Greg Fitzgerald <garious at gmail.com> wrote: > I've been thinking about how easy it would be to integrate lld into

On Thu, Jan 29, 2015 at 10:26 AM, Reid Kleckner <rnk at google.com> wrote: > It's not clear to me that this is worthwhile. I'd think you'd see value when new languages get off the ground faster because they don't need to think about linking. Dealing with all the subtle differences between the various system linkers is no fun. Maybe that's not a ton of value, but as I

On 29 Jan 2015, at 19:05, Greg Fitzgerald <garious at gmail.com> wrote: > > I'd think you'd see value when new languages get off the ground faster > because they don't need to think about linking. Dealing with all the > subtle differences between the various system linkers is no fun. > Maybe that's not a ton of value, but as I mentioned, the integration >

I'm hoping to revive the LLD standalone CMake build. I'm new to this build but it looks like it borrowed code from an old version of compiler-rt, which I did some work on last year. Like compiler-rt, I'd like to get the LLD build up running with only CMAKE_PREFIX_PATH instead of defining custom variables like LLD_PATH_TO_LLVM_BUILD and LLD_PATH_TO_LLVM_SOURCE. Any objection to that?

How do you feel about adding LLD to the LLVM repo? Could it follow the same path as the integrated assembler? That is, Clang keeps it off by default for each architecture until it's ready for prime time. -Greg On Thu, Jan 8, 2015 at 3:31 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Wed, Jan 7, 2015 at 6:38 PM, Greg Fitzgerald <garious at gmail.com> wrote:

I suspect the answer is "no" as it dies with a hard error for me. I don't want to fix this if it isn't being used; I would rather delete it and avoid the complexity it brings. Thoughts? This came up because I have changes to LLD's CMake build to support LLVM_LIBDIR_SUFFIX more effectively, but I can't test them in a standalone build. -Chandler -------------- next part

On 8 January 2015 at 19:46, Chandler Carruth <chandlerc at google.com> wrote: > > On Thu, Jan 8, 2015 at 4:35 PM, Greg Fitzgerald <garious at gmail.com> wrote: >> >> How do you feel about adding LLD to the LLVM repo? Could it follow >> the same path as the integrated assembler? That is, Clang keeps it >> off by default for each architecture until

I wanted to go through and map out the layering of LLD's libraries today and found that it's essentially impossible. I think some serious cleanup is needed here. Let's start with the purely link-level dependencies encoded in the CMake build: Curently the Core library depends on the ReaderWriter/Native library, which links against the ReaderWriter library, which links against the Core

You can email the list, what url says that? -Chris > On Jan 20, 2015, at 9:31 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > Ping > >> On Mon, Jan 19, 2015 at 9:52 AM, Greg Fitzgerald <garious at gmail.com> wrote: >> I am not a member of the llvm-admin email list and on the description >> of that page it says, "DO NOT MAIL THIS LIST!"

Below is a copy of the email I sent to llvm-admin. If it is lost in the ether, can you reply on this thread? There's an LLD contributor looking to add an ARMv7 backend. It's a significant contribution so I'd like to land the patch under the correct author. Hi LLVM admins, I'd like to commit patches on behalf of others, but I'm not comfortable simply adding "Patch by

After having read through this long thread, I'm having trouble spotting a case of someone saying lowerCamelCase variable names is a bad idea. Nick's original proposal looks good to me. What do we need to do to move forward here? Thanks, Greg On Tue, Oct 14, 2014 at 2:55 PM, Chris Lattner <clattner at apple.com> wrote: > > On Oct 13, 2014, at 4:31 PM, Chandler Carruth

I'm trying to back up our svn repositories, and I found a nice little backup command line bzip's the backup and creates the md5 hash all in one: svnadmin dump --deltas /repo |bzip2 |tee dump.bz2 | md5sum >dump.md5 The problem is I need to split the backups, so this doesn't really work. Is there perhaps another way of piping things to allow for splitting of the backups?

I created a subversion repository on my new vps and i''m trying to setup my rails app there. However i keep getting this error: subversion/libsvn_subr/io.c:2516: (apr_err=13) svn: Can''t create directory ''/home/svnadmin/rapleaf/db/transactions/0-1.txn'': Permission denied How do i fix this? I know others have had this before, so i would appreciate some help.

Sean, Thanks for doing this research and writing up that summary! The SECTION and MEMORY seem doable in lld as part of the ELF Writer. The one tricky part will be if the linker script defines symbols (e.g. __text_size), because those symbol names might be referenced by some object file atom. Thus they need an atom representation for lld's Resolver to see. So, the ELF Writer will need

> Cool, can you use clang 3.3 then? :) I can, but digging deeper I see that the compiler-rt sanitizer tests depend on just-built-clang for its object instrumentation. The next time the instrumentation changes, I'd expect those tests to break. If the lit tests that require -fsanitize were moved to the clang repo, then I think it'd be safe to build compiler-rt with clang 3.3 or gcc

Okay, dropping gcc 4.4.3 makes sense. How do you feel about using clang 3.2 (and the upcoming 3.3) instead of tip-of-the-trunk clang? It looks like everything works great, but that you just need to make those UB tests 'unsupported' since they fail with "libclang_rt.ubsan was built without __int128 support". Thanks, Greg On Mon, May 27, 2013 at 12:36 AM, Alexey Samsonov

> What is the exact line you use to configure build tree, and the output you see? cmake ../.. \ -G Ninja \ -DCMAKE_INSTALL_PREFIX=ship \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_ENABLE_ASSERTIONS=ON \ -DLLVM_TARGETS_TO_BUILD=ARM \ -DLLVM_DEFAULT_TARGET_TRIPLE=arm-none-linux-gnueabi \ -DLLVM_TARGET_ARCH=arm-none-linux-gnueabi \ -DLLVM_LIT_ARGS=-v ninja check-all

Following the advice here I''ve been trying to get subversion installed and working from my virtual dedicated server this weekend. I believe everything is installed properly, and that all that''s left is to get the apache httpd.conf file set up correctly. to talk to my server with my client I''m using the path: http://svn.mylittlecorneroftheinternet.com/svn/repos/ error

Hi, Thanks a lot for your answer. It seems lld is still the best solution, even if it does not work "right out of the box" for us today. We already have a solution for the "objcopy" part (added the required output format to llvm-objdump). The ScriptLayout class seems to be empty for now (on the master branch at least), but we do not need linker scripts today. All that is

Hello Renato, Thanks very much for raising the topic. I've not got much to add to what has already been said. If I understand correctly there are two use cases that we would want to consider separately: - Using lld by default when clang is used on a platform such as linux if it is installed. - Using lld by default in build-bots and the llvm test-suite when it is installed. For the former,