Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] size_t?"
2014 Sep 30
2
[LLVMdev] size_t?
Hi Reid,
I copied the x64 toolsets by hand; they got installed to C:\Program
Files (x86)\LLVM\tools\msbuild\x64; they just didn't get moved correctly
by install.bat.
I just verified that the LLVM-vs2013 toolset.props is correct.
If it is a bitness problem, perhaps I'm failing to define something
correctly?
Regards,
Eric
On 9/30/14, 11:29 AM, Reid Kleckner wrote:
> This looks
2014 Oct 01
2
[LLVMdev] size_t?
I believe that we provide a definition of size_t inside the compiler itself
when clang is in MSVC compatibility mode.
On Tue, Sep 30, 2014 at 5:51 PM, Eric Mader <emader at gmx.us> wrote:
> I did some more investigation of the size_t size error. I misunderstood
> what was happening. It turns out that size_t is already defined before my
> prefix header is included. I added the
2014 Oct 01
2
[LLVMdev] size_t?
We inject a typedef for size_t here:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/Sema.cpp?revision=218230&view=markup#l206
The typedef type is determined by calling getSizeType().
SizeType is (relevantly) calculated in two places:
X86_64
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?revision=218666&view=markup#l3512
X86_32
2014 Sep 30
2
[LLVMdev] Windows Installer
I replaced all instances of "$(Platform)" with "x64" for the x64 .props
file and it still fails, so it looks like that guess was wrong as well.
Regards,
Eric
On 9/29/14, 2:11 PM, Eric Mader wrote:
> Quoting doesn't seem to make a difference. Strangely, the Win32
> toolset seems to work. (Where "work" means that clang runs and
> produces a bunch of
2014 Sep 29
2
[LLVMdev] Windows Installer
Your install dir has a whitespace. Have you tried quoting? e.g.
<LLVMInstallDir>"C:\Program
Files (x86)\LLVM"</LLVMInstallDir>
Best regards,
Rafael Auler
On Mon, Sep 29, 2014 at 7:38 PM, Eric Mader <emader at gmx.us> wrote:
> I changed tooset-vs2013.props to this:
>
> <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
>
2014 Sep 29
2
[LLVMdev] Windows Installer
Open the file toolset-vs2013.props and you'll understand what's happening
and where the path is set. It tries to fetch the LLVM installation path
from the Windows registry. Just fix this (maybe editing your registry or
editing the .props file, whatever suits you best).
On Mon, Sep 29, 2014 at 5:33 PM, Eric Mader <emader at gmx.us> wrote:
> I copied the x64 toolsets by hand and
2014 Sep 29
4
[LLVMdev] Windows Installer
I was hoping to not have to build LLVM myself, especially on Windows.
Can anybody help me with the Windows installer?
Failing that, I find the directions for how to compile on Windows hard
to follow? Can I build using Cygwin?
Regards,
Eric
On 9/29/14, 8:11 AM, Rafael Auler wrote:
> I'm not sure about the Windows installer, but if you build and install
> LLVM for Windows from the
2014 Sep 29
4
[LLVMdev] Windows Installer
I’m trying to install LLVM-3.6.0-r218288-win32.exe on Windows 7 Ultimate
x64. The install doesn’t complain, but the toolset doesn’t show up in
either Visual Studio 2013 or Visual Studio 2010. Also I selected the
choices to add LLVM to the path for every user and put an LLVM icon on
the desktop. Neither of this happened. Can anyone tell me how to get
this to work?
Regards,
Eric Mader
2014 Oct 02
2
[LLVMdev] Header File Not Found?
I'm having a strange problem compiling with VS 2013. It's not finding a
header file that's there in one of the header file search dirs.
Here's the compile command (with the names changed to protect the
innocent ;-)
1> C:\Program Files (x86)\LLVM\msbuild-bin\CL.exe /c
/IC:\[top-level-dir]\[source-dir]\
/IC:\[top-level-dir]\[source-dir]\[sub-dir-1]
2014 Oct 01
2
[LLVMdev] -fblocks?
I'm trying to compile some C++ code on Windows that contains blocks. The
compiler gives me the error that the blocks language feature is not
enabled and that I should enable it with "-fblocks". When I add that
compiler flag, the compile fails immediately saying "unknown argument:
'-fblocks'"
Is this perhaps an incomplete feature?
Regards,
Eric Mader
2011 Feb 28
1
[LLVMdev] [cfe-dev] [PATCH] Windows improvements
Hello Erik,
Thank you to work. I have not checked to build them, though, I can
tell you some comments, excuse me.
* General
- Please post patches to cfe-commits and to llvm-commits, too.
(IMHO it would not be needed to split articles apart each lists as
long as each would be related.)
- If you can, please attach files w/o CRLF(dos encodings), or with
attached text/plain.
- You may
2014 Sep 30
2
[LLVMdev] Windows Installer
Hi Hans,
Answers inline below.
Regards,
Eric
On 9/30/14, 8:05 AM, Hans Wennborg wrote:
> On Mon, Sep 29, 2014 at 7:56 PM, Eric Mader <emader at gmx.us> wrote:
>> Hi Hans,
>>
>> I think installer.bat found my visual Studio installation because it
>> installed the Win32 toolsets but not the x64 ones. (It took me a while to
>> work this out ;-) I installed
2014 Sep 30
2
[LLVMdev] Windows Installer
Hi Hans,
I think installer.bat found my visual Studio installation because it
installed the Win32 toolsets but not the x64 ones. (It took me a while
to work this out ;-) I installed the x64 toolsets by hand and they seem
to work.
I think the installer ran as administrator. I explicitly ran it that way
again (asking it to uninstall first) just to be sure. It didn't seem to
make any
2014 Oct 01
2
[LLVMdev] Compiling As Obj-C or Obj-C++ On Windows
I have some C++ source files that mix in small bits of Obj-C. On the
Mac, these files are marked to be compiled as Obj-C++. Looking at the
clang help, it seems that the option for that is "-ObjC++". However,
when I add that in Additional Options I get an error message:
CL> : error : invalid integral value 'bjC++' in '-ObjC++'
I see this same message if I put
2014 Sep 30
2
[LLVMdev] Barking Up The Wrong Tree?
I'm trying to port a bunch of code from MacOS X to Windows. The code is
a mixture of C, C++11 and Objective-C. (Some of the C++ code has bits of
Objective-C mixed in, just for spice ;-) Since it builds on the Mac with
clang, I thought that building on Windows with clang would mean that I
wouldn't have to make a bunch of changes just related to a different
compiler. For example, if I
2014 Sep 30
4
[LLVMdev] Barking Up The Wrong Tree?
Hi Reid,
Thanks for the reply. Comments inline below.
Regards,
Eric
On 9/29/14, 5:51 PM, Reid Kleckner wrote:
> I think any port will involve some changes, but it's really hard to
> say which porting approach will be the least painless beforehand.
> Aside from _MSC_VER incompatibilities messing up portability headers,
> I think any changes you make to support clang on Windows
1999 Nov 17
3
file permissions and smbmount
I'm using Samba 2.0.6 on a Linux server.
When using smbmount or mount to mount a share from an NT server, how do I
set file permissions. An older smbmount allowed a -d and -f switch to set
the file permissions. The newest one does not support these. The man pages
for smbmount and smbmnt mention using syntax that does not work.
I finally have gotten the mount command to work, but now I
2015 Jun 08
3
[LLVMdev] msbuild and clang
I'm trying to compile some large programs with clang on Windows (with a
view to compiling to bit code and then running some whole program
optimisations on the bit code).
Take for example the Python 2.7 interpreter:
As is typically the case, the usual build procedure involves running
msbuild which invokes the Microsoft compiler.
The most obvious procedure would then be to substitute
2018 May 16
2
Windows build strangeness
I think MSBuild isn't capable of re-running cmake and then reloading the
project files when CMakeLists.txt changes. It re-runs cmake, but then
continues the build with the stale projects. That probably explains the
"PipSqueek.cxx doesn't exist" errors. As for the link error, it could also
be caused by things like a file rename not getting picked up by MSBuild.
The fix is
2018 May 16
2
Windows build strangeness
With VS2013 I found that editing a CMakeLists.txt file caused CMake to be re-run successfully and the build to also continue successfully, but since I switched to VS2015 the CMake re-run occurs - apparently successfully, but more often than not the build failed afterwards from either the IDE and from MSBuild. Since I seldom change the CMakeLists.txt files, I simply do a clean CMake configuration