search for: r168779

...specified library will be converted into a directive that starts with > "/DEFAULTLIB" in the COFF .drectve section. To demonstrate, the following > patch > produces directives that work with Visual Studio 2010 using the > now-deprecated > dependent library feature (commits r168779 and r168694). > Is that feature now-deprecated? The documentation here: http://msdn.microsoft.com/en-us/library/7f0aews7.aspx only talks about the "exestr" comment type being deprecated. I see that the /defaultlib flag itself to the linker is deprecated, but it isn't clear to m...

...pecified library will be converted into a directive that starts with >> "/DEFAULTLIB" in the COFF .drectve section. To demonstrate, the following patch >> produces directives that work with Visual Studio 2010 using the now-deprecated >> dependent library feature (commits r168779 and r168694). > Is that feature now-deprecated? The documentation here: > http://msdn.microsoft.com/en-us/library/7f0aews7.aspx > only talks about the "exestr" comment type being deprecated. > I see that the /defaultlib flag itself to the linker is deprecated, but it isn'...

....) semantics is that each specified library will be converted into a directive that starts with "/DEFAULTLIB" in the COFF .drectve section. To demonstrate, the following patch produces directives that work with Visual Studio 2010 using the now-deprecated dependent library feature (commits r168779 and r168694). /* beginning of patch */ Index: /home/ygao/LLVM/llvm/lib/Target/X86/X86AsmPrinter.cpp =================================================================== --- /home/ygao/LLVM/llvm/lib/Target/X86/X86AsmPrinter.cpp (revision 165914) +++ /home/ygao/LLVM/llvm/lib/Target/X86/X86AsmP...

On Nov 27, 2012, at 6:23 PM, Jason SH Lin <jasonlin.mtk at gmail.com> wrote: > Dears, > > If you remove this keyword, will you keep the backward compatibility in LLVM 3.x? > > We use this keyword in our project for checking dependent libraries, and we rely on the promise that bitcode format will keep compatible in LLVM 3.x. In our project, we compile and save bitcodes for

Dears, If you remove this keyword, will you keep the backward compatibility in LLVM 3.x? We use this keyword in our project for checking dependent libraries, and we rely on the promise that bitcode format will keep compatible in LLVM 3.x. In our project, we compile and save bitcodes for later use, but we always try to keep our runtime upstream. Hence, we need readers recognize previous version

Hi all, We plan to add some auto-linking support for Mach-O, and need a scheme for encoding this information in the LLVM IR. We would like the same scheme to be able to support Microsoft's #pragma comment(lib,...) and #pragma comment(library, ...) features eventually. The current proposal is as follows: -- #1. Extend module-level metadata flags (llvm.module.flags) to support two new