Hi folks,
I've been trying to get gcc to support native windows TLS for a while
now. I think I'm close to the point where I'll be able to submit to
gcc (the code works for me and I have a huge w32 codebase) - And it's
working for a while, actually).
I thought to let you know, because, perhaps, th
Is anyone able to compile and run the following example with mingw-w64?
https://msdn.microsoft.com/en-us/library/windows/desktop/aa379945(v=vs.85).aspx
It compiled for me, but complains at runtime about
CryptGetDefaultProviderA missing entry point.
It seems like mingw-64 defines the import lib fo
On Tue, Aug 25, 2015 at 9:59 AM, Ray Donnelly
wrote:
> On Tue, Aug 25, 2015 at 1:53 PM, Gisle Vanem wrote:
> > I was under the impression that:
> >f:\MingW32\MingW-w64\bin\gcc.exe
> >
> > was just a driver for the right gcc.exe.
> > True or false?
>
> False. Back when Apple used GCC they had
See tdm-gcc, it works like that.
On Mon, Aug 24, 2015 at 7:05 PM, Spork Schivago
wrote:
> Hi.
>
> Is it possible to cross-compiling using pre-compiled binaries of
> mingw-w64? I'm running Windows 7, 64-bit, and I'd like to be able to
> install the compiler and make either 32-bit only applicati
On Mon, Aug 10, 2015 at 7:34 AM, Jacek Caban wrote:
> Hi David,
>
>
>
> I'm sorry for the delay, I was sure I already replied. The patch looks
> mostly good and ready to be committed IMO. There is one minor thing:
>
> -#ifndef _INTSAFE_H_INCLUDED_
> -#define _INTSAFE_H_INCLUDED_
> +#pragma once
>
Em qua, 1 de jul de 2015 às 02:36, Greg Jung escreveu:
> In my programming instead of "multibytetowide" conversion preparing for a
> windows API inside #ifdef UNICODE blocks, I just call the ANSI mode of
> the function with ascii c-strings
> passed in, and let microsoft perform the A->W convers
>
> [cut]
> This may also help in future: http://lmgtfy.com/?q=c%2B%2B+toupper
>
>
ROTFL! I didn't know that one.
As for std::toupper, IIRC there's an override which takes a locale
argument. But I'm not sure mingw-w64 support locales other than C in that
case. Last time I checked libstdc++ didn't
Grasp this sentence: implementation dependent.
wchar_t is wide char, it's made to imply that each representable character
can take more than one byte to encode a character. It was created before
utf8 got mainstream. And, as there were competing encodings (UCS-2 fixed
length vs what ended up being
facilities that Microsoft provides when it comes to the
> API, after all, it is their API for Windows OS. Nonetheless, thanks to
> your help the porting has become much easier, thanks man.
>
> *From:* Alexandre Pereira Nunes
> *Sent:* Monday, June 29, 2015 8:04 PM
> *To:* mingw
It seems like you're not passing -lwinmm to the linker. I use this:
LDFLAGS := -Wl,--as-needed -lgdi32 -lcomdlg32 -lws2_32 -lwinmm
-Wl,--no-as-needed
to selectively link these libraries. I'm not sure if the "as-needed" logic
is required on windows, but it works for me™.
What it does is only ref
A bad alloc could mean your process got out of virtual address space. The
most likely cause would be a memory leak. Make 100% sure you're freeing
every allocated resource or use a memory leak tool to diagnose it. Perhaps
you have threads leaving that aren't deallocating everything. For instance
don
I came across this: https://sourceforge.net/p/mingw-w64/bugs/344/
Does anyone knows if that's still the case?
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourcefo
If GCC is able to interoperate with simple vtables in 32-bits, as you say,
then perhaps it's only a matter of setting some options. gcc manual (IIRC)
says that you need -maccumulate-outgoing-args -mabi=ms on x86_64 for
microsoft abi compatibility (while -mabi=ms suffices in 32-bit). -mabi=ms
is sup
On Wed, Jun 17, 2015 at 1:08 PM, Ruben Van Boxem
wrote:
>
>>
> This is most likely an ABI issue yes, because you are relying on the
> binary interface of the app and dll to be the same (i.e. the objects are
> assumed to have the same memory layout and alignment and padding and
> whatnot). Unfortu
Yes, you can say it's an ABI issue. There are generally no C++ ABI
provisions for inter-compiler (complex) object passing. You have only
moderate access to influence name mangling (via extern "C" { } constructs)
and calling convention (stdcall and friends), but inheritance has other
requirements (V
Well, I never ran Clang before, so this'll be an opportunity :-)
Em seg, 8 de jun de 2015 às 19:07, Ivan Garramona <
heavenandhell...@gmail.com> escreveu:
> 2015-06-08 10:07 GMT-03:00 Yaron Keren :
>
>> Ah yes, for gcc it is required.
>> Have you looked at clang implementation? it support native
sn't mingw-w64 released under a public domain or
> CC0 license?
>
>
> http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/5238f91b.7010...@tdragon.net/
>
>
> 2015-06-08 15:41 GMT+03:00 Alexandre Pereira Nunes <
> alexandre.nu...@gmail.com>:
>
>>
Hi,
I read in the mailing list archives that some work was done on the area of
implementing native TLS support and I'm interested in continuing it, in
case nobody is currently on it.
My initial goal would be to have an implementation that would be both
thread-model agnostic (i.e. be both sufficien
18 matches
Mail list logo
