similar to: adding msvcr100.dll interception support to compiler-rt ?

The Wine maintenance release 2.0.2 is now available. What's new in this release (see below for details): - Various bug fixes The source is available from the following locations: http://dl.winehq.org/wine/source/2.0/wine-2.0.2.tar.xz http://mirrors.ibiblio.org/wine/source/2.0/wine-2.0.2.tar.xz Binary packages for various distributions will be available from:

On Thu, Oct 23, 2014 at 2:46 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > 2014-10-23 11:34 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: >> On Thu, Oct 23, 2014 at 2:24 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> I don't think this is the right approach. >>> >>> Currently we intentionally define malloc etc

On Thu, Oct 23, 2014 at 3:38 PM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Thu, Oct 23, 2014 at 2:57 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >> On Thu, Oct 23, 2014 at 2:46 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> 2014-10-23 11:34 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: >>>> On Thu, Oct

compiler-rt libs must be built with /MT, so the MSVS build is doing the wrong thing here. 2014-10-23 12:52 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: > On Thu, Oct 23, 2014 at 3:42 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >> On Thu, Oct 23, 2014 at 3:38 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >>> On Thu, Oct 23, 2014 at 2:57

On Wed, Oct 8, 2014 at 12:17 PM, Greg Bedwell <gregbedwell at gmail.com> wrote: > Hi, > > To follow up from Paul last week: > >> I'm expecting to have our internal builds switched over later this >> week. Our investigations have shown no problems. > > We've now updated our internal builds from 2012.4 (cl.exe 17.0.61030) to > 2013.3 (cl.exe

I think this issue is that we were not using the INTERCEPTOR macros to define these functions. The following patch seems to work for me to get the build linking again, however, I cannot test -- when I run check-asan, I get: 2> lit.py: lit.common.cfg:59: fatal: Invalid llvm_tools_dir config attribute: 'E:/llvm/2013/$(Configuration)/bin' ~Aaron On Thu, Oct 23, 2014 at 1:20 PM, Aaron

> On Aug 22, 2014, at 9:53 AM, Daniel Dilts <diltsman at gmail.com> wrote: > > On Fri, Aug 22, 2014 at 9:42 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: > Starting a new thread to loop in cfe-dev and lldb-dev. For those not following along there has been a thread on llvm-dev about moving the minimum required Visual Studio version to

Hi, I have tagged 3.6.2-final, so testers can start building and uploading -final binaries. There was only one change between 3.6.2-rc1 and 3.6.2-final, which was a patch to the R600 backend to fix the build with VS2012. Running a full regression suite is probably not necessary, but you still can if you want to be extra careful. -Tom

Hi all APFloat.h contains this code, which was required for Visual Studio builds. Given that this was committed in r41784 (2007), does anyone know if newer versions work? I think after moving to C++11 we’re on VS2013 at a minimum? I’d have hoped it would be more likely to work. Thanks, Pete /// What kind of floating point number this is. /// /// Only 2 bits are required, but

pls read the page of http://llvm.org/builds/ : To use the LLVM toolchain from Visual Studio, select a project in Solution Explorer, open its Property Page (Alt+F7 by default), and in the "General" section of "Configuration Properties" change "Platform Toolset" to "LLVM-vs2010" or "LLVM-vs2012". Alternatively, invoke MSBuild with

>From this website: http://llvm.org/builds/ I've installed the LLVM toolchain on 2 Windows machines. One with Visual Studio 2012 and another with Visual Studio 2013. After installing the LLVM toolchain neither machine shows the LLVM option in the Visual Studio project properties pane where you can select which toolchain to use for the project. Am I missing a step somewhere? :) Thanks for

On Thu, Oct 23, 2014 at 2:24 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > I don't think this is the right approach. > > Currently we intentionally define malloc etc without changing the > names and (when stuff works ok) the linker just links all the mem > allocator calls with calls to our RTL. This is kind of a link-time > interception. How could that work

The Wine development release 2.3 is now available. What's new in this release (see below for details): - Obsolete wineinstall script removed. - More Direct3D command stream work. - A few more Shader Model 5 instructions. - Better underline rendering in DirectWrite. - Improved ODBC support on 64-bit. - Various bug fixes. The source is available from the following locations:

I'd like to raise our baseline Windows system requirements to Vista, dropping support for running LLVM on Windows XP. Microsoft dropped support for XP half a year ago in April 2014. Our current status is that we require VS 2012 to build LLVM, and VS 2012 only runs on Vista+, but it has the ability produce binaries that run on XP. During the C++11-pocalypse, users expressed interest in keeping

lvqcl wrote: > 1) > Current MSVC solution (FLAC.sln and numerous .vcproj files) was made with > VC2005 Express and doesn't allow to build 64-bit files/libraries. > > IMHO it's time to add 64-bit support for MSVC builds, but AFAIK only Visual Studio > 2012/2013 Express are free and allow to build 64-bit files. > > VS 2005/2008 use .vcproj files, and VS

On 6.5.2013 0:43, Timothy B. Terriberry wrote: > Janne Hyv?rinen wrote: >> You people do realize these hacks would only be required for 10+ year >> old obsolete compilers? > No, they're required for easy distribution on 12 year old OSes (which, > last I saw, make up almost 40% of Firefox's desktop userbase, and likely > will continue to for some time). > What

On 31 October 2013 09:41, Douglas Gregor <dgregor at apple.com> wrote: > Not quite :). At present, we (= Apple) still have some dependencies on > building top-of-tree Clang with VS2010. We’re currently investigating how > quickly we can move those to VS2012 or newer. > Hi Doug, Good to know. Since this is mostly related to 3.5, we still have half-a-year to make sure it

Hello! I'm wondering whether compiler-rt is expected to be buildable with MSVC 2013. I am currently getting: Error 49 error LNK2005: _free already defined in asan_malloc_win.obj E:\llvm\crt_build\lib\asan\MSVCRT.lib(MSVCR120.dll) Which seems to be the only issue (aside from ~50 warnings, which I'll happily work on cleaning up). I get this when I build the ALL_BUILD project in the

> -----Original Message----- > From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On > Behalf Of Aaron Ballman > Sent: Monday, September 29, 2014 4:45 PM > To: Chris Bieneman > Cc: lldb-dev at cs.uiuc.edu; cfe-dev Developers; LLVM Developers Mailing List > Subject: Re: [cfe-dev] [LLVMdev] [RFC] Raising LLVM minimum required MSVC > version to 2013

As the title suggests, what is the status of compiling llvm on versions of MSVC less than 2012? Not so much "Does it work?", but more like "Should any thought be given to whether or not something will break it?" Right now there are a bunch of warnings when compiling LLDB on Windows because it uses various symbols which have been defined since VS2012, but which are re-defined