Hi
I've been doing some experiments with clang and mingw.
clang reports the mingw com headers are incorrect.
It says comdef.h at line 164 has this definition.
void _com_issue_error(HRESULT hr) throw(_com_error) {
But comip.h has this definition.
void WINAPI _com_issue_error(HRESULT);
and tha
Hi Everyone
I can't build the popular build program ninja with clang++ and mingw.
The reason is demonstrated by this simple program:
// wcx.cpp
#include
using namespace std;
#include
int main()
{
wchar_t* p = wcschr(L"hello", L'h');
}
Compiling this program with g++ yields the same probl
Hi Everyone
I thought you might want to know that if I use clang 3.5 from trunk to
compile mingw's windows.h file like so:
// w3.cpp - no main even
#include
clang++ -fms-extensions w3.cpp
I get errors the errors shown below. I emailed one of the guys on the clang
team to ask what they thought w
Hi Kai
I applied your patch, the output was this:
C:\mingw\x86_64-w64-mingw32\include>patch -p0 stdio.h < stdio.diff
patching file stdio.h
patch unexpectedly ends in middle of line
Hunk #6 succeeded at 833 with fuzz 1.
The message didn't make me feel confident about the patch, but I was able
to b
Hi Everyone
A recent change to clang has begun considering a header in mingw
as defective.
The header appears to be re-declaring functions with different attributes.
I thought someone here might want to know about that. I am using a mingw
4.8.2 ruben build from 2013 (I think).
Sorry if the situ
Hello Everyone
I'm trying to track a few tricky problems with stralign.h
I was looking at this previously but had to drop it but I'm now looking at
it again.
Consider this program (distilled from stralign.h):
#define TRUE 1
#define WSTR_ALIGNED(s) TRUE
inline int strwhatever(const char* String1
Hi
Just to correct my previous message, the alternative stralign.h I
found doesn't work for me after all when building Ninja, I made a mistake
building it before to think it did work.
So the diff I provided for further info in my previous message may not be
that useful
So to recap, I'm using str
Hi Jon
How is your second answer any fuller than your first?
I'm no expert in mingw or I wouldn't be asking such simple questions to
begin with.
If you had provided a link to a more recent version of stralign.h you are
referring to as I asked, I could have tried it myself plus everything else
wit
Hi Jon,
Thanks for replying but could you be a bit more fuller with your answer
please.
What do mean by "use a newer version"?
Of what, from where?
If you mean gcc/mingw, the version I linked in my previous message is here:
http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/
Hello Everyone
Could you please help me. I'm using mingw 4.8.1 obtained from here:
http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/64-bit/threads-win32/seh/x64-4.8.1-release-win32-seh-rev3.7z/download
I use mingw to build ninja from source with libcxx from source on W
Hi Ruben
Thanks for that.
I've posted a patch to Howard with a fix as you have suggested now, because
the warnings fill my screen up and I am building often and in light of the
other opinions it might be the only fix on offer for now. I think Howard is
planning to commit it tomorrow his time. I'v
locale.cpp
regardless.
Sorry if this message goes to the wrong place. I often try to add to an
existing thread but it comes in as a new one. I'm still working this out.
On Thu, Apr 11, 2013 at 11:52 PM, Ruben Van Boxem
wrote:
> 2013/4/11 G M
>
>> I agree with both Ruben and Corrina
I'll submit a patch to libcxx and watch out
to see if someone comes up with that a more creative solution in libc++.
I'll be impressed if they do, and more impressed if it doesn't cause more
problems later on. lol
On Thu, Apr 11, 2013 at 10:08 PM, Corinna Vinschen wrote:
> On
macro '_isupper_l'
#define _isupper_l(_Char,_Locale) _ischartype_l(_Char,_UPPER,_Locale)
^
c:/mingw/bin/../lib/clang/3.3/../../../x86_64-w64-mingw32/include\ctype.h:203:154:
note: expanded from macro '_ischartype_l'
#define _ischartype_l(_Char,_F
Hello Everyone
I'm using one of Rubens 4.8 based personal builds and clang. When I compile
with either I get this warning when using _isupper(c).
Do you know if it is correct to say that a ptrdiff_t or some such cast
inside this macro would make this warning go away.
If so, I hope somebody who see
It does work as long as the destination directory already exists.
But I am thinking it might not work if a file (as opposed to a
directory) is being copied and the destination directory doesn't exist,
then I am concerned that what might happen is that cmake is going to copy
the file and give it the
Hi Everyone
This is my first time posting here. Sorry while I work out how to do it
properly.
Ruben
Your wchar_t fopen change makes sense to me, at least compared to the
alternatives suggested in this thread.
Do you know if it make senses in the context of Beman Dawes' C++ filesystem
proposal?
17 matches
Mail list logo
