similar to: [LLVMdev] [RFC]Extending lib/Linker to support bitcode "shared objects"

On 08/12/11 03:56 PM, Ivan Krasin wrote: > Hi llvm team! > > I'm currently working on the extended version of llvm-ld, which has an > ability to check if all the symbols present (and fail if some symbols > are not resolved), treat archives in the right way (link all the object > files in the archive if it's specified as the regular input, not as -l) Is that the

On Sun, Dec 11, 2011 at 2:19 PM, Rafael Ávila de Espíndola < rafael.espindola at gmail.com> wrote: > On 08/12/11 03:56 PM, Ivan Krasin wrote: > > Hi llvm team! > > > > I'm currently working on the extended version of llvm-ld, which has an > > ability to check if all the symbols present (and fail if some symbols > > are not resolved), treat archives in

On Tue, Dec 13, 2011 at 9:27 PM, Rafael Ávila de Espíndola < rafael.espindola at gmail.com> wrote: > > > $ llc bar.bc -filetype=obj -o bar.o > > $ clang -shared -o bar.so bar.o > > $ clang -use-gold-plugin foo.o bar.so -o t > > > > Is that correct? In particular, "lld t" should show a dependency on > bar. > > Any

> Is it more clear now? If not, I would like to give it another try and > write much more details and examples. I am still not completely sure I understand the use case. In particular since you say you want a bitcode module in the end, I don't understand how this is different from using llvm-link, it doesn't complain about undefined symbols... Can you provide an example? What are

> $ llc bar.bc -filetype=obj -o bar.o > $ clang -shared -o bar.so bar.o > $ clang -use-gold-plugin foo.o bar.so -o t > > Is that correct? In particular, "lld t" should show a dependency on bar. > Any particular reason for not adding this to the plugin api? > > The result is a native .so here. My goal is to have a bitcode result. > >

On Sat, Oct 15, 2011 at 7:35 PM, Ivan Krasin <krasin at google.com> wrote: > I'm not related to the topic starter, but I see at least one huge > disadvantage of the dependency on link.exe. > W/o such a dependency it would be possible reliably generate Windows > executables on Linux or Mac, which has its own benefits (e.g. > distributed compilation) GRUB, the Grand Unified

On Sat, Oct 15, 2011 at 12:26 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Sat, Oct 15, 2011 at 7:38 AM, Thomson <lilotom at gmail.com> wrote: >> I just found that some samples used link.exe from Visual Studio to generate >> the final image, does LLVM has a replacement for link.exe to generate the >> final binary? I'm not related to the topic

Here is a revised patch after some suggestions: 1. Removed extraneous changes (the white space changes that are -/+ whitespace), and the commented out code. 2. Keep the warning for linking dynamic libraries in LinkLibraries.cpp I still don't have a good solution to the problem of -L paths that include bytecode versions of the native libraries we're trying to link. Consider the

On Mon, Mar 18, 2019 at 8:02 PM Rui Ueyama <ruiu at google.com> wrote: > On Thu, Mar 14, 2019 at 1:05 PM bd1976 llvm via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Thu, Mar 14, 2019 at 6:27 PM Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> >>> >>> On Thu, Mar 14, 2019 at 6:08 AM bd1976 llvm via

On Sun, Mar 24, 2019 at 9:51 PM Saleem Abdulrasool <compnerd at compnerd.org> wrote: > Sorry for the late chiming in. > > Yes, swift does use autolinking, and I would like to use that on all the > targets. The only target which does not support this functionality > currently are ELF based. That said, I think that `#pragma comment(link, > ...)` is insufficient for my

On Thu, Mar 21, 2019 at 12:06 AM Rui Ueyama <ruiu at google.com> wrote: > Perhaps there's no one clean way to solve this issue, because previously > all libraries and object files are explicitly given to the linker via a > command line and the order of files in the command line matters. That > assumes human intervention to work correctly. Now, the autolinking feature >

Are you planning to add support for "-F" and "-framework" to ELF linkers? On Mon, Mar 25, 2019 at 12:51 AM Saleem Abdulrasool via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Sorry for the late chiming in. > > Yes, swift does use autolinking, and I would like to use that on all the > targets. The only target which does not support this functionality >

Hi everyone, I wanted to mention a project using LLVM: Emscripten. Emscripten is an open source LLVM to JavaScript compiler, http://emscripten.org https://github.com/kripken/emscripten/ There are various demos linked to on the wiki (the first link), of various large C/C++ codebases compiled to JS and running on the web, like Python, Bullet, Poppler, etc. Emscripten is not a

Thanks Saleem/James. On Tue, Mar 26, 2019 at 5:15 AM Saleem Abdulrasool <compnerd at compnerd.org> wrote: > Yes, I don't think that supporting all options is entirely possible. But, > there is certainly some allure to it, as it is a really powerful feature > (which you can tell from the behaviour of link and `.drectve` section). > The problem with all options is that

On Thu, Mar 14, 2019 at 6:27 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > > > On Thu, Mar 14, 2019 at 6:08 AM bd1976 llvm via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> At Sony we offer autolinking as a feature in our ELF toolchain. We would >> like to see full support for this feature upstream as there is anecdotal >> evidence that

On Fri, Dec 16, 2011 at 7:14 PM, Alon Zakai <azakai at mozilla.com> wrote: > > > ----- Original Message ----- >> From: "Eli Friedman" <eli.friedman at gmail.com> >> To: "Alon Zakai" <azakai at mozilla.com> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Thursday, December 15, 2011 7:02:34 PM >> Subject: Re: [LLVMdev] Emscripten:

----- Original Message ----- > From: "Eli Friedman" <eli.friedman at gmail.com> > To: "Alon Zakai" <azakai at mozilla.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Thursday, December 15, 2011 7:02:34 PM > Subject: Re: [LLVMdev] Emscripten: LLVM => JavaScript > On Thu, Dec 15, 2011 at 4:10 PM, Alon Zakai <azakai at mozilla.com> > wrote: >

On Thu, Dec 15, 2011 at 4:10 PM, Alon Zakai <azakai at mozilla.com> wrote: > On that topic, I see there is an LLVM users page, > > http://llvm.org/Users.html > > - what is the procedure for suggesting adding a project to > there? Send a patch to llvm-commits. > The third issue I want to raise is regarding closer > integration with LLVM. Right now, Emscripten uses

This buildbot seems to have been failing for a while (though it's hard for me to identify the root cause in the logs, as I mentioned in another thread, so it's hard to say if it's the same failure, or if the failure is consistent, etc) - anyone watching it/caring aobut it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Wed, Sep 30, 2015 at

Okay, so where should I send questions for WebAssembly? Is it this mailing list or a different one? I want to ask about how to compile WebAssembly modules with Clang directly, without Emscripten, for situations like what I have currently where I have a problem with generating WebAssembly and/or JavaScript glue code (I have a problem with the gen_struct_info stuff; I asked on the Emscripten