search for: flavors

...hat you want here. a) LLVM could be built just for one target(LLVM_TARGETS_TO_BUILD) b) With LTO this case might happen more often, where an user would have compiled LLVM just for one architecture and lld would support other architectures that LLVM would not support. c) Printing all the targets/flavors that the linker currently supports. On Oct 7, 2014, at 2:03 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: >> Hi, >> >> I think lld needs to have an infrastructure as part of the build process to build specific flavors and specific targets. > This sounds like...

On Wed, Oct 8, 2014 at 11:45 AM, Alex Rosenberg <alexr at leftfield.org> wrote: > This it totally "armchair quarterbacking," but I am a little frustrated > that we've come to conflate flavors and targets. > > The original intent of flavors was to internally translate each flavor > into a neutral lld-native command line syntax. We now have baked in > assumptions of behavior based on flavor. > > If I want to cross-compile from OS X for Windows PECOFF, I don't think i...

I'm trying to install my first channel of FAX. When I run the benchfax utility, I get to various stages and then the program simply hangs. There is no excessive CPU utilization and the benchfax program readily responds to ^C. Sometimes I get fairly far into the test, other times it hangs almost immediately. The version of benchfax version I'm using is 1.0.7. I heard tell of a newer

Hi, I think lld needs to have an infrastructure as part of the build process to build specific flavors and specific targets. For this I was thinking that the Registry expand to consider flavors and targets that are part of the build process. So each flavor/target would register and the Driver would walk through the list of handlers to check if there is a handler defined for that flavor/target....

I build llvm/clang/lld from source on Windows using mingw-64/gcc-6.3. I use clang++ both to test clang targeting gcc and clang targeting VC++. When using clang targeting VC++ I use the appropriate target triple when compiling and am trying to use lld to link the object file(s) into an exe. To do that I use the clang option "-fuse-ld=lld" when linking. According to the llvm doc on

Hi all, According to lld/docs/Driver.rst, Flavor command line option determines the style of lld command-line interface when invoked. However, it looks like this option also determines the set of supported targets we are linking for. For example, lld -flavor gnu cannot link mach-o binaries, and could not link PE binaries either (well, not until rL312926). Is this really intended by the design

Michael, I'm looking at flushing out the mach-o driver and targetinfo. Can we rename the "ld64" flavor to "darwin". The command line tool on MacOSX is called "ld" - just like on unix. The name ld64 is the current source repository name for the linker. Once lld takes over, the term ld64 won't mean anything. I've worked through adding DarwinOpts.td

On Thu, Oct 10, 2013 at 9:16 AM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 10/9/2013 11:19 PM, Rui Ueyama wrote: > >> >> Isnt having a YAML file starting with the below better, so that you dont >> need to go through file extensions. >> >> magic : >> arch: >> >> I guess we will use a fixed file extension anyway (we probaly

Martell recently added "ld64.lld" as a name for the Darwin driver. As to why there's no driver that provides a unified command line arguments, I can't speak for other people. But no one seems to have been interested in it enough to actually invent and implement a set of unified command line arguments. On Thu, Oct 26, 2017 at 2:20 PM, N <scandium at me.com> wrote: >

..., g wrote: > > > On 06/07/2015 07:25 PM, Kay Schenk wrote: > <<>> > >> So, I'm not sure how to interpret what you said. Can I get the same >> results from a CentOS install using some combination of options? > > because your are playing with multi flavors, > [i bet you like going to baskin-robbins for ice cream ;-) ] > a solution for you would be what i did some years back and i was > playing with diff flavors, my "/home" partition was mounted in > new install as /home2 and i let installation setup a /home in /. > > aft...

Hi Nick, There are already a lot of options that are being shared across various flavors. Adding a new option becomes a issue when that option need to available across all flavors. As the first step, I am thinking of consolidating the common options shared across all the Unix variant flavors in CommonOptions.td. The options that are shared between Darwin/GnuLD are :- a) -o b) -L...

I mean, there is such a universal driver -- it's called "clang". On Oct 26, 2017 5:31 PM, "Rui Ueyama via llvm-dev" <llvm-dev at lists.llvm.org> wrote: Martell recently added "ld64.lld" as a name for the Darwin driver. As to why there's no driver that provides a unified command line arguments, I can't speak for other people. But no one seems to

# is a line comment chracter in YAML so it's valid. That's why I wrote a simple magic "comment". On Thu, Oct 10, 2013 at 6:21 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 10/10/2013 5:00 PM, Rui Ueyama wrote: > >> On Thu, Oct 10, 2013 at 9:16 AM, Shankar Easwaran >> <shankare at codeaurora.org>**wrote: >> >> On

On 10/9/2013 11:19 PM, Rui Ueyama wrote: > > Isnt having a YAML file starting with the below better, so that you dont > need to go through file extensions. > > magic : > arch: > > I guess we will use a fixed file extension anyway (we probaly don't want to > use .txt for YAML object file for example), so what do you think is the > benefit of depending on special

On 10/10/2013 5:00 PM, Rui Ueyama wrote: > On Thu, Oct 10, 2013 at 9:16 AM, Shankar Easwaran > <shankare at codeaurora.org>wrote: > >> On 10/9/2013 11:19 PM, Rui Ueyama wrote: >> >>> Isnt having a YAML file starting with the below better, so that you dont >>> need to go through file extensions. >>> >>> magic : >>> arch:

On Wed, Jan 23, 2013 at 6:57 PM, Nick Kledzik <kledzik at apple.com> wrote: > Michael, > > I'm looking at flushing out the mach-o driver and targetinfo. > > Can we rename the "ld64" flavor to "darwin". The command line tool on MacOSX is called "ld" - just like on unix. The name ld64 is the current source repository name for the linker. Once

On Sep 18, 2013, at 12:18 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > There are already a lot of options that are being shared across various flavors. Adding a new option becomes a issue when that option need to available across all flavors. > > As the first step, I am thinking of consolidating the common options shared across all the Unix variant flavors in CommonOptions.td. > > The options that are shared between Darwin/GnuLD ar...

On Wed, Oct 9, 2013 at 7:57 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 10/9/2013 4:19 PM, Shankar Easwaran wrote: > >> On 10/9/2013 3:09 PM, Nick Kledzik wrote: >> >>> On Oct 9, 2013, at 11:23 AM, Shankar Easwaran <shankare at codeaurora.org> >>> wrote: >>> >>>> We have a whole bunch of readers(we would have

Ah Sorry. Totally forgot about that. On 10/10/2013 8:24 PM, Rui Ueyama wrote: > # is a line comment chracter in YAML so it's valid. That's why I wrote a > simple magic "comment". > > > On Thu, Oct 10, 2013 at 6:21 PM, Shankar Easwaran > <shankare at codeaurora.org>wrote: > >> On 10/10/2013 5:00 PM, Rui Ueyama wrote: >> >>> On Thu,

...hould be to convert command line args into this big struct. And, for debugging, the driver should have a way to take an instance of the big struct and dump it into command line args (like -###). Given that model, the question is, is there one big struct that is the union of all options from all flavors? Or a base struct and a subclass for each flavor. I prefer the subclass per flavor approach. -Nick