similar to: [LLVMdev] Status of compiling on MSVC < 2012

> 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

Attached are two patches with MSVC build enchancements. They are quite trivial, but were necessary to correctly link LLVM libraries with Mesa3D on Windows. Jose -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-to-build-against-static-MSVC-runtime.patch Type: text/x-patch Size: 2055 bytes Desc: not available URL:

José Fonseca <jose.r.fonseca at gmail.com> writes: > Attached are two patches with MSVC build enchancements. > > They are quite trivial, but were necessary to correctly link LLVM > libraries with Mesa3D on Windows. [snip] > add_llvm_definitions( -D_SCL_SECURE_NO_DEPRECATE ) > + add_llvm_definitions( -D_SECURE_SCL=0 ) With this setting the default LLVM build becomes

On 09-03-13 01:01, Erik de Castro Lopo wrote: > I would like to know how many years I have to wait before we can ditch > this stuff. I intend to do some testing on platforms I have available > today and roll a second pre-release after my testing. Talking about ditching, there are still .dsp files in the repository, these are MSVC 6 files. I haven't seen anyone on the list testing

(re-sending to the actual mailing lists... go go gadget typos!) On Sun, Oct 27, 2013 at 2:23 AM, Chandler Carruth <chandlerc at google.com>wrote: > Greetings, > > This has been discussed many times, and there are a lot of pro's and con's > on each side, but increasingly I think the project needs to draw a line in > the sand and put in place long-term policies around

On Oct 27, 2013, at 12:07 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Chris Lattner <clattner at apple.com> writes: > >>> One short term caveat: Windows is special. > > s/Windows/Visual Studio. > > MinGW has the latest and greatest gcc. > >> I don't see how it is special. > > It is special, sadly, and I'm not talking about C++11

> -----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

I have moved onto the next phase and committed r229185, which makes VS2013 our minimum version. I will revert if issues arise, and we can rinse and repeat as necessary. Once it sticks for a bit I’ll update the docs too. -Chris > On Feb 9, 2015, at 10:07 AM, Chris Bieneman <beanz at apple.com> wrote: > > I agree with Aaron, this should not be a blocker because the workaround is

To the mailing list this time... On Sat, Mar 6, 2010 at 4:26 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Sat, Mar 6, 2010 at 4:19 PM, José Fonseca <jose.r.fonseca at gmail.com> wrote: >>>> --- a/include/llvm/System/DataTypes.h.cmake >>>> +++ b/include/llvm/System/DataTypes.h.cmake >>>> @@ -100,6 +100,9 @@ typedef u_int64_t uint64_t;

In DataTypes.h starting on line 121 are these lines: #define INT8_C(C) C #define UINT8_C(C) C #define INT16_C(C) C #define UINT16_C(C) C #define INT32_C(C) C #define UINT32_C(C) C ## U #define INT64_C(C) ((int64_t) C ## LL) #define UINT64_C(C) ((uint64_t) C ## ULL) They are conflicting with the cstdint when we have updated headers in our MSVC build. I could have sworn I talked about this

If we have no other major users who require VS 2012 support, I think it's reasonable to officially switch now. We might want to wait for 3.6 to go out the door, just to reduce possible issues with porting fixes, but that may be overly cautious. ~Aaron On Wed, Jan 28, 2015 at 7:16 AM, Greg Bedwell <gregbedwell at gmail.com> wrote: > This thread seems to have stalled again without

Hi everyone, As Kevin has just announced, wxruby-swig has been moved into CVS as a toplevel project. It still is not in a "releasable" form yet, but it now builds on more systems than it doesn''t, and is moving towards stability. Because of the complexity of the build environment, we''re using rake (http://rake.rubyforge.org) as a build system instead of the standard

The .dsp and .dsw files included I obtained as a part of the vorbis source, via CVS, are not recognized by Visual Studio as valid workspace/project files. Should I be getting these files from another place or can someone clue me in on how else to build vorbis on a windows platform? Scott Danahy Programmer VedaLabs - www.vedalabs.com --- >8 ---- List archives: http://www.xiph.org/archives/

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

MSVC survives because there's no effective competition- it's like communications providers in the United States or political parties in China. The alternatives like GCC have no decent development environments for them, and Clang has the bonus of not being mature w.r.t. things like Standard libraries. The reality is, there's nowhere to go *but* MSVC. This stuff is the major reason why

Apart from the obvious licencing issues, each time I have moved from one version of VC++ to another, the big problem I have had is not specifically the ABI at the register passing, stack organisation level, but rather the implementation details of the Standard C++ libraries, and in particular the STL containers. While the compiler team puts considerable effort into maintaining the ABI, the C++

Hi, As I understand it the specific issue we're seeing is related to what Martin described. But due to numerous bugs found when mixing objects compiled with different versions of MSVC in the past, we now are shy of doing it even if it seems to work superficially - that's no guarantee bugs won't be found down the line. We'd much prefer to stay within the realms of what Microsoft

I'll need to dig up the references for that... but I'm pretty sure the universal CRT that debuted in MSVC 2015 only covers the C parts, and not the C++ parts. On 9/7/2016 4:28 PM, Zachary Turner wrote: > It's worth pointing out that from 2015 and on, they claim to support > full forwards compatibility of the standard libraries, so this should > (in theory) never be an

LLVM's typedefs for int32_t etc. under MSVC (in Support/DataTypes.h) conflict with those used by other third-party libraries. Instead of these: #ifdef _MSC_VER typedef __int64 int64_t; typedef unsigned __int64 uint64_t; typedef signed int int32_t; typedef unsigned int uint32_t; typedef short int16_t; typedef unsigned short uint16_t; typedef signed char int8_t; typedef unsigned char uint8_t;

On Fri, Aug 22, 2014 at 8:58 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 22 August 2014 13:43, Aaron Ballman <aaron at aaronballman.com> wrote: >> My opposition to this switch was the timing. When we researched "what >> minimum can we live with for C++11" nine months ago, we determined >> what versions would make sense, which included MSVC