search for: arseni

This is really unfortunate. I've read the discussion threads for the atom/chunk controversy and I feel like I understand the reasons for rewriting the linker, but this does not seem to have anything to do with whether the linker is usable as a library or not. As it stands, not only does lld have two completely different linkers (I'm treating COFF/ELF2 as one since they are really two

----- Original Message ----- > From: "Rafael Espíndola via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Yaron Keren" <yaron.keren at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Arseny Kapoulkine" <arseny.kapoulkine at gmail.com> > Sent: Tuesday, January 26, 2016 9:39:34 AM > Subject: Re: [llvm-dev] lld:

In the process of migrating from old lld ELF linker to new (previously ELF2) I noticed the interface lost several important features (ordered by importance for my use case): 1. Detecting errors in the first place. New linker seems to call exit(1) for any error. 2. Reporting messages to non-stderr outputs. Previously all link functions had a raw_ostream argument so it was possible to delay the

Hello speex development team! As I see on http://www.speex.org/downloads/ page, where is no Windows binaries for speex encoder and decoder tools for 1.2beta2 version since no maintainer for it yet. Well, I compiled it from the sources using MSYS environment and MinGW tools (GCC version is 3.4.5). Both libOgg-1.1.3 and speex-1.2beta2 were configured as "./configure

I think I have an idea to cover your need and possibly other people's on this thread. It provides the "main() as a library function" feature, input/output files wouldn't go through disks nor file systems, and it doesn't require any major design changes. Sounds too good? That is, we can provide a function that takes command line parameters, do fork, and call the linker's

> If I were a user, I definitely want the former instead of the latter because the former just provides more. This is if you wanted to use the library (e.g. embed linker into clang, do parallel linking of many executables from the same process, etc.). For some use cases there's no difference because the only thing you'll do with a library is link it into a command-line executable and

If you want to link ELF object files, you are likely to be using a Unix machine. I'm not trying to address all possible problems but suggesting a practical solution. On Fri, Jan 22, 2016 at 9:49 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > On Windows fork() is not available. If exec() is used instead, process > creation time is several times slower than Linux. This may be

As a person who started this thread I should probably comment on the interface. My needs only require a library-like version of a command-line interface. Just to be specific, the interface that would work okay is the old high-level lld interface: bool link(ArrayRef<const char*> args, raw_ostream& diagnostics) This would require round-tripping data through files which is not ideal but

Hi, I am using version libvirt on debian lenny from backports repository, version 0.7.6-1~bpo50+1, amd64. Th functionality of "virsh net-edit" command is not very clearly documented, and I think it should change a configuration of a running network. But I see it doesn't. So, I want to add new host, for example: #I have old configuration root at xxx:/etc/libvirt/qemu/networks#

> Also, one of the other possible motivations of using LLD directly from Clang would be to avoid process overhead on operating systems where that is a much more significant part of the compile time cost. We could today actually take the fork out of the Clang driver because the Clang frontend *is* designed in this way. But we would also need LLD to work in this way. Then go change clang and

Hi Rui I agree separating the components out in to libraries only makes sense when there is a clear reason to do so. However, just this year there was a very involved discussion about what it means to be a library. Specifically, I don't think your current 'main-as-library' argument is valid while you call exit or (if you) rely on mutable global state. Having a single entry point

On 7/27/07, Ivo Emanuel Gon?alves <justivo@gmail.com> wrote: > On 7/24/07, Arseny Krasutsky <dtiger@mail.ru> wrote: > > So I can send this binaries to you if you want to place it online. > > I'm sure people need it :-) > > I do not know Jean-Marc's position on this -- it's his project, so I > don't want to meddle -- but if he does not oppose, I

On Thu, Jan 7, 2016 at 4:05 PM Rui Ueyama <ruiu at google.com> wrote: > By organizing it as a library, I'm expecting something coarse. I don't > expect to reorganize the linker itself as a collection of small libraries, > but make the entire linker available as a library, so that you can link > stuff in-process. More specifically, I expect that the library would >

On Thu, Jan 7, 2016 at 7:18 AM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> In the process of migrating from old lld ELF linker to new (previously >> ELF2) I noticed the interface lost several important features (ordered by >>

The context issue may be solved by making all functions and context data members of a class. Sort of having the convenience of global variables accessible from all linker functions but without the regular global variable problems of initializing and re-entry. so the class is suitable aspart of a library. Most clang and LLVM classes works this way, not passing contexts around. 2016-01-22 6:25

On Fri, Dec 16, 2016 at 11:18 AM, Pete Cooper <peter_cooper at apple.com> wrote: > Hi Rui > > I agree separating the components out in to libraries only makes sense > when there is a clear reason to do so. However, just this year there was a > very involved discussion about what it means to be a library. > Specifically, I don't think your current

On Thu, Jan 7, 2016 at 3:18 PM Rui Ueyama <ruiu at google.com> wrote: > On Thu, Jan 7, 2016 at 2:56 PM, Chandler Carruth <chandlerc at gmail.com> > wrote: > >> On Thu, Jan 7, 2016 at 7:18 AM Rui Ueyama via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev < >>>

> On Dec 16, 2016, at 11:46 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Fri, Dec 16, 2016 at 11:18 AM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote: > Hi Rui > > I agree separating the components out in to libraries only makes sense when there is a clear reason to do so. However, just this year there was a very

On Thu, Jan 7, 2016 at 6:07 PM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Jan 7, 2016 at 5:12 PM, Chandler Carruth <chandlerc at gmail.com> > wrote: > >> On Thu, Jan 7, 2016 at 4:05 PM Rui Ueyama <ruiu at google.com> wrote: >> >>> By organizing it as a library, I'm expecting something coarse. I don't >>>

> On Dec 17, 2016, at 6:32 PM, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Fri, Dec 16, 2016 at 12:31 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> On Dec 16, 2016, at 11:46 AM, Rui Ueyama <ruiu at google.com <mailto:ruiu at google.com>> wrote: >>