similar to: [LLVMdev] Macro redefinitions

In the llvm file include/llvm/Support/DataTypes.h (.in/.cmake), for MSVCit defines some macros that are defined in the cstdint.hpp file in boost (and boost does it better, detailed below): The basic error is: R:\SDKs\boost\built_head\include\boost-1_38\boost/cstdint.hpp(347) : warning C4005: 'INT8_C' : macro redefinition

OvermindDL1 <overminddl1 at gmail.com> writes: [snip] > If you are curious, the remaining non-pedantic warnings are: > > An actual warning that should be fixed: > 4>r:\sdks\llvm\trunk\utils\tablegen\CodeGenDAGPatterns.h(27) : warning > C4099: 'llvm::Init' : type name first seen using 'class' now seen > using 'struct' [snipped some more

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

I made this change (not specifically changing from a list to a string, but changing from a hardcoded value to the value that was actually decided by cmake), and I checked that it works with cmake 2.8.12.2 which is the minimum version set in CMakeLists.txt. So if it doesn’t work with cmake 3.1/3.2 then that looks like something new that was introduced after 2.8.12.2. I’ll have a look at this

LLVM_DEFINITIONS used to be defined as set(LLVM_DEFINITIONS "-D__STDC_LIMIT_MACROS" "-D__STDC_CONSTANT_MACROS") Now it is defined as set(LLVM_DEFINITIONS " -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS") (note that it is no longer a cmake list but a string, and the string contains a leading space!) This causes CMake 3.1 to emit g++ -D

Hi! In DataTypes.h (generated from DataTypes.cmake) there is an extra code path for Visual C. This can produce macro redefinitions for INT8_MAX, INT8_MIN etc. since other headers may also define them. Therefore please protect the macros like INT8_C etc. Also it would be nice if the auto-generated HAVE_STDINT_H and HAVE_INTTYPES_H would be used also for Visual C since it is possible to add them

Le 06/03/2010 11:43, José Fonseca a écrit : > 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 > > Are you volontary trying to break everyone build (just to build your own project), or have you no idea of the effect of this change:

This patch splits LLVM_USE_CRT into new CMake variables LLVM_USE_CRT_DEBUG, LLVM_USE_CRT_RELEASE, etc (one for each build type). It also automatically detects which CRT was already chosen by CMake's defaults in the CMAKE_CXX_FLAGS_* variables, and defaults to those values. (Before, it was using add_llvm_definitions(), which worked...somehow, but CMAKE_CXX_FLAGS_RELEASE and friends were still

[please CC the llvm mailing list] Jochen Wilhelmy <j.wilhelmy at arcor.de> writes: >> What's that extra code path? >> > > #ifndef _MSC_VER > ... > #else /* _MSC_VER */ > /* Visual C++ doesn't provide standard integer headers, but it does provide > built-in data types. */ > > ... extra code path ... > > #endif Sorry, that doesn't

On Sat, Mar 6, 2010 at 11:33 AM, Cédric Venet <cedric.venet at laposte.net> wrote: > Le 06/03/2010 11:43, José Fonseca a écrit : >> >> 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 >> > > Are you volontary

If cmake happens to detect GCC for the C compiler and Clang for the C++ compiler, then a manual override of either the C compiler or SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG is required. This has been happening on my Darwin build environments: -- The C compiler identification is GNU 4.2.1 -- The CXX compiler identification is Clang 4.1.0 Without the manual overrides, all C sources fail to compile

nobled <nobled at dreamwidth.org> writes: > This patch splits LLVM_USE_CRT into new CMake variables > LLVM_USE_CRT_DEBUG, LLVM_USE_CRT_RELEASE, etc (one for each build > type). It also automatically detects which CRT was already chosen by > CMake's defaults in the CMAKE_CXX_FLAGS_* variables, and defaults to > those values. > > (Before, it was using

On Sun, Nov 25, 2012 at 3:19 PM, Joe Abbey <jabbey at arxan.com> wrote: > If cmake happens to detect GCC for the C compiler and Clang for the C++ > compiler, then a manual override of either the C compiler or > SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG is required. This has been happening > on my Darwin build environments: > > -- The C compiler identification is GNU 4.2.1 >

Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> writes: > On Mon, Jun 20, 2016 at 05:05:18PM +0000, Paweł Bylica via llvm-dev wrote: >> On Sun, Jun 19, 2016, 17:57 Joerg Sonnenberger <joerg at bec.de> wrote: >> >> > On Sun, Jun 19, 2016 at 03:24:22PM +0000, Paweł Bylica via llvm-dev wrote: >> > > Hi LLVM, >> > > >>

http://bugzilla.mindrot.org/show_bug.cgi?id=1299 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Comment #3 from dtucker at zip.com.au 2007-04-29 14:06

This patch protects against redefinitions of size_t. There are currently at least two different definitions provided with klibc: unistd.h -> stddef.h -> bits32/bitsize/stddef.h sys/times.h -> linux/times.h -> linux/types.h both define size_t, causing gcc to complain. I suspect ptrdiff_t has a similar problem; not covered by this patch. Regards, Erik diff -urN

http://bugzilla.mindrot.org/show_bug.cgi?id=1299 Summary: Remove redefinition of _res in getrrsetbyname.c Product: Portable OpenSSH Version: 4.5p1 Platform: All OS/Version: NetBSD Status: NEW Keywords: patch Severity: major Priority: P2 Component: ssh AssignedTo: bitbucket at mindrot.org

On Wed, Feb 24, 2016 at 8:02 AM, Pete Batard via Syslinux <syslinux at zytor.com> wrote: > I get a redefinition warning on _GNU_SOURCE when compiling with MinGW, and > while I could see that this #define was introduced in e4fc44 [1], but the > reason to introduce it is not mentioned, and I can't really see a good > reason to have it, especially as MSVC will happily compile

Hi, I have the following trouble with samba 2.0.5a, I have defined my printers as follows: in the global section: printcap name = /etc/printcap load printers = yes printing = lprng print command =/usr/bin/lpr -U%m -P%p -r %s;echo %m %M>>/var/log/samba/printlog lpq command = /usr/bin/lpq -U%m -P%p lprm command = /usr/bin/lprm -U%m -P%p %j lppause