search for: linker

Displaying 20 results from an estimated 7457 matches for "linker".

1999 Aug 03
2
compliation problem
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
2016 Oct 28
9
LLD to be the default linker in Clang
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)...
2018 May 11
2
[RFC] (Thin)LTO with Linker Scripts
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...
2016 Oct 28
0
[cfe-dev] LLD to be the default linker in Clang
...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...
2018 Jan 08
2
Linker Option support for ELF
...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...
2015 Feb 09
2
[LLVMdev] lld options to parse linker script
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>
2016 Oct 30
0
[cfe-dev] LLD to be the default linker in Clang
....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...
2018 Jan 04
8
Linker Option support for ELF
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...
2014 Aug 04
2
[LLVMdev] LLVM Basic Program Compilation
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...
2018 Jan 08
0
Linker Option support for ELF
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...
2018 Jan 04
0
Linker Option support for ELF
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...
2018 May 14
0
[RFC] (Thin)LTO with Linker Scripts
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...
2018 Jan 04
1
Linker Option support for ELF
...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...
2016 Oct 31
2
[cfe-dev] LLD to be the default linker in Clang
...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...
2019 Mar 14
11
RFC: ELF Autolinking
...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...
2015 May 04
4
[LLVMdev] LLD improvement plan
...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...
2015 May 01
15
[LLVMdev] LLD improvement plan
...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...
2019 Mar 14
2
RFC: ELF Autolinking
...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...
2016 Oct 28
0
LLD to be the default linker in Clang
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...
2015 May 04
0
[LLVMdev] LLD improvement plan
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...