similar to: [LLVMdev] llvm-config --cxxflags is not consistent when building by cmake.

Dear LLVM user and developer, We get a chance to give a tutorial on LLVM and MCLinker. The tutorial will be co-located with CGO 2013 on Feb. 24 (Sunday morning) in Shenzhen, China. If you are also interesting in these topics, welcome to join the tutorial! Here is a website of the tutorial: http://code.google.com/p/mclinker/ We're also looking for additional presenters to share a

Luba Tang <lubatang at gmail.com> writes: > We found `llvm-config --cxxflags' does not have -fno-exceptions -fno-rtti > when using cmake to build LLVM. > Does anyone know how to fix it? Using -fno-rtti and -fno-exceptions is an internal LLVM policy. There is no reason to impose it on client code.

Hi, Brooks, Since this project is helped by many BSD guys in Taiwan, one of MCLinker's main objectives is make direct contribution to the BSD realm. Please feel free to give us suggestions to make sure we can achieve this goal. Any comments are appreciated. We realized open discussion on the mailing list is necessary, and we hope this thread can be a beginning to openly discuss the project

On Tue, Nov 1, 2011 at 18:24, Tang Luba <lubatang at gmail.com> wrote: > In GCC, LTO causes 'fat' object files, because GCC needs to serialize > IR into 'intermediate language' (IL) and compress IL in object files. > In our experience, the 'fat' object files are x10 bigger than the > original one, and slow down the linking process significantly. The >

Hi Óscar, On 22/11/12 09:41, Óscar Fuentes wrote: > Luba Tang <lubatang at gmail.com> writes: > >> We found `llvm-config --cxxflags' does not have -fno-exceptions -fno-rtti >> when using cmake to build LLVM. >> Does anyone know how to fix it? > > Using -fno-rtti and -fno-exceptions is an internal LLVM policy. There is > no reason to impose it on client

On Tue, Nov 01, 2011 at 10:34:43PM +0800, Jush Lu (?c?|?s) wrote: > Hi all, > > We are developing a linker, MCLinker. > > MCLinker is a linker for LLVM. It leverages the LLVM machine code (MC) > layer to link object files and bitcodes, and generate shared objects > and executable files. Cool! A linker has been the largest gap for FreeBSD to move to a completely BSD

Hi all, We are developing a linker, MCLinker. MCLinker is a linker for LLVM. It leverages the LLVM machine code (MC) layer to link object files and bitcodes, and generate shared objects and executable files. Motivation ---------- The development of MCLinker was started out of the need for an LLVM integrated linker. LLVM lacks an integrated linker; hence, it relies on external linkers to

2011/11/1 Jush Lu (盧育龍) <Jush.Lu at mediatek.com>: > Hi all, > > We are developing a linker, MCLinker. > > MCLinker is a linker for LLVM. It leverages the LLVM machine code (MC) layer to link object files and bitcodes, and generate shared objects and executable files. > > > Motivation > ---------- > > The development of MCLinker was started out of the need

Hi all, The slides we used on "CGO MCLinker and LLVM Tutorial" are now available on the MCLinker website: http://code.google.com/p/mclinker/wiki/2013CGOTutorial Enjoy! - The CGO Tutorial on MCLinker and LLVM 2013 committee

On 03/19/2015 09:24 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 9:18 AM, Reed Kotler <reed.kotler at imgtec.com > <mailto:reed.kotler at imgtec.com>> wrote: > > Well, you are an mclinker contributor > > > Me personally? Not that I know of. Sorry. I thought i had seen your name in an mclinker commit. > > and Google uses mclinker >

On Sep 7, 2009, at 6:43 PM, kito wrote: > Hello everybody > > I am newbie in llvm and compiler, I have some questions about llvm's > capability - How large project llvm can compile now? > I mean, such as linux kernel or ggc...llvm can build it? > especially on the other architecture, ARM or alpha > because I must choice one between gcc and llvm to study. > In my long

Well, you are an mclinker contributor and Google uses mclinker and now it's broken as the result of your change. I still don't see any justification to making a change in a public interface that is used by other non LLVM projects to fix some issue with clang warnings. People should be able to derive from those classes. I can't understand your reasoning as to why these classes must

Hello, I tried to build an own R package on Windows XP but get an error which I can't solve. I called my package "pack". It works to creat the file "pack" with package.skeleton(). But when I try to compile it with Rcmd build --binary pack I obtain the following error: IO::Seekable::seek missing at C:/R/R-2.9.0/share/perl/FileHandle.pm line 59. Compilation failed in

On 03/19/2015 09:38 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 9:34 AM, Reed Kotler <reed.kotler at imgtec.com > <mailto:reed.kotler at imgtec.com>> wrote: > > On 03/19/2015 09:24 AM, David Blaikie wrote: >> >> >> On Thu, Mar 19, 2015 at 9:18 AM, Reed Kotler >> <reed.kotler at imgtec.com <mailto:reed.kotler at

On 03/19/2015 09:57 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 9:52 AM, Reed Kotler <reed.kotler at imgtec.com > <mailto:reed.kotler at imgtec.com>> wrote: > > On 03/19/2015 09:38 AM, David Blaikie wrote: >> >> >> On Thu, Mar 19, 2015 at 9:34 AM, Reed Kotler >> <reed.kotler at imgtec.com <mailto:reed.kotler at

On 03/19/2015 08:55 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 4:30 AM, Reed Kotler <Reed.Kotler at imgtec.com > <mailto:Reed.Kotler at imgtec.com>> wrote: > > One could argue that mclinker is doing something good or not by > how it's using this class > but I don't see the need for parser<bool> to be final. That is a >

Let's suppose that MCLinker folks are here already - I am a committer of this project :). Maybe I did not formulate my suggestion correctly. When I offer to "install" the yaml2obj and obj2yaml utilities I mean result of the "make install" command only. I do not suggest to include this utilities into any distributed binary packages. To be clear I attached the patch with

One could argue that mclinker is doing something good or not by how it's using this class but I don't see the need for parser<bool> to be final. That is a subjective opinion that mclinker needs to be changed. I think that "final" was added to some of these command line classes to avoid some kind of clang warning. That seems wrong to me that the tools are dictating

//===----------------------------------------------------------------------===// // FalseParser //===----------------------------------------------------------------------===// class FalseParser : public parser<bool> { public: explicit FalseParser(Option &O) : parser<bool>(O) { } // parse - Return true on error. bool parse(cl::Option& O, StringRef ArgName, StringRef

Hi all, As you might already know, there is a CGO tutorial talking about MCLinker and LLVM [1]. If you have interest in this topic, please don't hesitate to join us. ;) I, one of the co-oragnizers, are going to give a presentation talking about "LLVM Intermediate Representation". This presentation has three subjects: - LLVM's lowering flow - The intermediate