search for: linker

Problem compiling R. version: 0.64.2 machine: SGI O2 OS: IRIX6.5 CC cc FC f77 MAKE GNU make 3.75 Here is part of the the output for make. make[2]: Leaving directory `/usr/people/faculty/math/mgass/stage/R/R-0.64.2/src/include' make[2]: Entering directory `/usr/people/faculty/math/mgass/stage/R/R-0.64.2/src/appl' cc -g -OPT:IEEE_NaN_inf=ON -I../include

Folks, I'm creating a bootstrap buildbot on AArch64 with LLD and I just realised the "accepted" way to make clang call lld is to "symlink lld -> ld". I understand that's how every Linux system "chooses" the linker, but that makes deployment and validation quite cumbersome on GNU systems. I'd like to suggest a change in behaviour: // Some flag like --linker=<full path / bin on path> if (LinkerFlag) { linker = Flag (linker); // triple != host } else if (CROSS_COMPILE) { if (LLDSupports(triple)...

RFC: (Thin)LTO with Linker Scripts At the last US LLVM Developers' Meeting, we presented [1] a proposal for linker script support in (Thin)LTO. In this RFC, I would like to describe the proposal in more detail and invite the community's feedback, so we can build consensus on the upstream implementation. The end go...

...t;cfe-dev at lists.llvm.org> wrote: > I'm creating a bootstrap buildbot on AArch64 with LLD and I just > realised the "accepted" way to make clang call lld is to "symlink lld > -> ld". I understand that's how every Linux system "chooses" the > linker, but that makes deployment and validation quite cumbersome on > GNU systems. There's also -fuse-ld= That's how I usually do it. > I'd like to suggest a change in behaviour: > > // Some flag like --linker=<full path / bin on path> > if (LinkerFlag) { > linker...

...vm.org> wrote: > >>> > >>> > >>> > >>> On Jan 7, 2018 5:02 PM, "Cary Coutant via llvm-dev" > >>> <llvm-dev at lists.llvm.org> wrote: > >>> > >>> > I think we all agree that blindly allowing the linker to honor the > >>> > options > >>> > would be scary. I agree that we should whitelist the options, and am > >>> > of the > >>> > opinion that we should force validation on the linker side (use of > any > >>> > option whi...

Hi all, Which are the command-line options available to pass linker script, library path etc.. to lld? I see minimal options listed, when i say, lld -flavor gnu -help Thanks in advance, -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150209/e7a6f7b8/attachment.html>

....llvm.org> wrote: > Folks, > > I'm creating a bootstrap buildbot on AArch64 with LLD and I just > realised the "accepted" way to make clang call lld is to "symlink lld > -> ld". I understand that's how every Linux system "chooses" the > linker, but that makes deployment and validation quite cumbersome on > GNU systems. > > I'd like to suggest a change in behaviour: > > // Some flag like --linker=<full path / bin on path> > if (LinkerFlag) { > linker = Flag (linker); > > // triple != host > } else...

Hello all, There was some interest from a number of a few people about adding support for embedded linker options to ELF. This would be an extension that requires linker support to actually work, but has significant prior art with PE/COFF as well as MachO both having support for this. The desire here is to actually add support to LLVM to pass along the necessary information into the object file. In...

Hi Waxiado, Chris and Tim, when i compiled with : > $ clang++ -g try.cpp `llvm-config --cppflags --ldflags --libs core jit > native`-o3 -S -emit-llvm I get the following warnings > clang: warning: -lz: 'linker' input unused > clang: warning: -lpthread: 'linker' input unused > clang: warning: -lcurses: 'linker' input unused > clang: warning: -lm: 'linker' input unused > clang: warning: -lLLVMX86Disassembler: 'linker' input unused > clang: warning: -lLLVMX...

I was thinking specifically of the subset of the commands for dealing with files, for example INPUT, GROUP and SEARCH_DIR. I agree that it would not be wise to allow the full generality of linker scripts. Thinking about this a bit more I think my main concern is that we should try hard to make sure that any commands that are embedded in an object file are compatible with any equivalent linker script commands. On 8 January 2018 at 17:35, Rui Ueyama <ruiu at google.com> wrote: > On...

On Wed, Jan 3, 2018 at 4:02 PM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > Hello all, > > There was some interest from a number of a few people about adding support > for embedded linker options to ELF. This would be an extension that > requires linker support to actually work, but has significant prior art > with PE/COFF as well as MachO both having support for this. > > The desire here is to actually add support to LLVM to pass along the > necessary information in...

Hello Tobias, Thanks very much for the RFC, I think that this will be useful in persuading embedded developers to use LTO in their projects. I think the overall approach for communication between the linker and code generator sounds reasonable. I've got some questions/comments based on some experience with Arm's proprietary linker, which supports LTO but has a different linker script mechanism than GNU ld compatible linkers. I'm not hugely familiar with the details of LTO at the moment so...

...n Silva <chisophugis at gmail.com> wrote: > > > On Wed, Jan 3, 2018 at 4:02 PM, Saleem Abdulrasool <compnerd at compnerd.org> > wrote: > >> Hello all, >> >> There was some interest from a number of a few people about adding >> support for embedded linker options to ELF. This would be an extension >> that requires linker support to actually work, but has significant prior >> art with PE/COFF as well as MachO both having support for this. >> >> The desire here is to actually add support to LLVM to pass along the >> nece...

...t;> Folks, >> >> I'm creating a bootstrap buildbot on AArch64 with LLD and I just >> realised the "accepted" way to make clang call lld is to "symlink lld >> -> ld". I understand that's how every Linux system "chooses" the >> linker, but that makes deployment and validation quite cumbersome on >> GNU systems. >> >> I'd like to suggest a change in behaviour: >> >> // Some flag like --linker=<full path / bin on path> >> if (LinkerFlag) { >> linker = Flag (linker); >> &g...

...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 it would find use beyond Sony. In general autolinking (https://en.wikipedia.org/wiki/Auto-linking) allows developers to specify inputs to the linker in their source code. LLVM and Clang already have support for autolinking on ELF via embedding strings, which specify linker behavior, into a .linker-options section in relocatable object files, see: RFC - http://lists.llvm.org/pipermail/llvm-dev/2018-January/120101.html LLVM - https://llvm.org/do...

...and inescapable > tensions, and Alex summarized how Camp B has been steering LLD away > from what Camp A people want. This isn’t bad in and of itself, because > what Camp B wants is clearly and unarguably good for LLVM. However, > it is also not sufficient, and while innovation in the linker space > (e.g. a new “native” object file format generated directly from > compiler structures) may or may not actually “work” or be “worth it”, > we won’t know unless we try, and that won’t fulfill its promise if > there are compromises to Camp B. It has been said in this thread before...

...with the current LLD architecture *The current LLD architecture has, in my opinion, two issues. *The atom model is not the best model for some architectures *The atom model makes sense only for Mach-O, but it’s used everywhere. I guess that we originally expected that we would be able to model the linker’s behavior beautifully using the atom model because the atom model seemed like a superset of the section model. Although it *can*, it turned out that it’s not necessarily natural and efficient model for ELF or PE/COFF on which section-based linking is expected. On ELF or PE/COFF, sections are units...

...r ELF toolchain. We would >> like to see full support for this feature upstream as there is anecdotal >> evidence that it would find use beyond Sony. >> >> In general autolinking (https://en.wikipedia.org/wiki/Auto-linking) >> allows developers to specify inputs to the linker in their source code. >> LLVM and Clang already have support for autolinking on ELF via embedding >> strings, which specify linker behavior, into a .linker-options section in >> relocatable object files, see: >> >> RFC - http://lists.llvm.org/pipermail/llvm-dev/2018-Ja...

I did not realize LLD was already far enough along to use. I have a related question: What about using LLD via library API? I would love to link against LLD and call API functions instead of trying to find the system linker and spawning a child process and having different code for each system linker. If I could use LLD as a library that would be one less moving part in my compiler, one less potential thing that could go wrong for my users. On Fri, Oct 28, 2016 at 12:17 PM, Renato Golin via llvm-dev < llvm-dev a...

On May 1, 2015, at 12:31 PM, Rui Ueyama <ruiu at google.com> wrote: > Proposal > Re-architect the linker based on the section model where it’s appropriate. > Stop simulating different linker semantics using the Unix model. Instead, directly implement the native behavior. Preface: I have never personally contributed code to LLD, so don’t take anything I’m about to say too seriously. This is not a...