So I tested it on my side with following code:
t.dll:
__thread int g_var = 1;
__declspec(dllexport) int get_g_var (void)
{
return g_var;
}
__declspec(dllexport) void set_g_var (int v)
{
g_var = v;
}
and t2.exe:
#include
#include
typedef int (*f1)(void);
typedef void (*f2)(int);
int main
2012/3/16 Chris Sutcliffe :
> Hi Kai,
>
> This issue has recently been raised in the MinGW tracker:
>
> http://sourceforge.net/tracker/?func=detail&atid=102435&aid=3322937&group_id=2435
>
> Basically there seems to be an issue with TLS and LoadLibrary. Given
> that mingw-w64 also uses TLS, how did
2012/3/16 Vincent Torri
> On Fri, Mar 16, 2012 at 5:18 PM, Ruben Van Boxem
> wrote:
> >
> > You can also use AR= and similar for the missing stuff.
>
> sure, but the cross compilation should work without modification.
>
That's the thing: my toolchains (at least the windows ones) aren't
cross-co
On Fri, Mar 16, 2012 at 5:18 PM, Ruben Van Boxem
wrote:
>
> You can also use AR= and similar for the missing stuff.
sure, but the cross compilation should work without modification.
> Did you try specifying build as well?
i don't understand
Vincent Torri
--
Hi Kai,
This issue has recently been raised in the MinGW tracker:
http://sourceforge.net/tracker/?func=detail&atid=102435&aid=3322937&group_id=2435
Basically there seems to be an issue with TLS and LoadLibrary. Given
that mingw-w64 also uses TLS, how did you work around it?
Thank you,
Chris
2012/3/16 Vincent Torri
> On Fri, Mar 16, 2012 at 5:11 PM, Ruben Van Boxem
> wrote:
> > 2012/3/16 Vincent Torri
> >>
> >> On Fri, Mar 16, 2012 at 4:54 PM, Ruben Van Boxem
> >> wrote:
> >> > 2012/3/16 Vincent Torri
> >> >>
> >> >> On Fri, Mar 16, 2012 at 4:22 PM, Ruben Van Boxem
> >> >> wrote
On Fri, Mar 16, 2012 at 5:11 PM, Ruben Van Boxem
wrote:
> 2012/3/16 Vincent Torri
>>
>> On Fri, Mar 16, 2012 at 4:54 PM, Ruben Van Boxem
>> wrote:
>> > 2012/3/16 Vincent Torri
>> >>
>> >> On Fri, Mar 16, 2012 at 4:22 PM, Ruben Van Boxem
>> >> wrote:
>> >> > 2012/3/16 Vincent Torri
>> >> >>
>>
2012/3/16 Vincent Torri
> On Fri, Mar 16, 2012 at 4:54 PM, Ruben Van Boxem
> wrote:
> > 2012/3/16 Vincent Torri
> >>
> >> On Fri, Mar 16, 2012 at 4:22 PM, Ruben Van Boxem
> >> wrote:
> >> > 2012/3/16 Vincent Torri
> >> >>
> >> >> hey
> >> >>
> >> >> in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7
On Fri, Mar 16, 2012 at 4:54 PM, Ruben Van Boxem
wrote:
> 2012/3/16 Vincent Torri
>>
>> On Fri, Mar 16, 2012 at 4:22 PM, Ruben Van Boxem
>> wrote:
>> > 2012/3/16 Vincent Torri
>> >>
>> >> hey
>> >>
>> >> in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7z, ar.exe is also named
>> >> x86_64-w64-mingw32
于 2012/3/16 23:22, Ruben Van Boxem 写道:
> I think it is. These seem to be related to GCC plugins, and do not
> appear in my 4.6.4 build for example. When I try to run them, I get an
> error about the program not being built with plugins (probably cause I
> didn't enable them explicitely in binuti
2012/3/16 Vincent Torri
> On Fri, Mar 16, 2012 at 4:22 PM, Ruben Van Boxem
> wrote:
> > 2012/3/16 Vincent Torri
> >>
> >> hey
> >>
> >> in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7z, ar.exe is also named
> >> x86_64-w64-mingw32-gcc-ar.exe and not x86_64-w64-mingw32-ar.exe. Is it
> >> normal ?
>
On Fri, Mar 16, 2012 at 4:22 PM, Ruben Van Boxem
wrote:
> 2012/3/16 Vincent Torri
>>
>> hey
>>
>> in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7z, ar.exe is also named
>> x86_64-w64-mingw32-gcc-ar.exe and not x86_64-w64-mingw32-ar.exe. Is it
>> normal ?
>
>
> I think it is. These seem to be related
2012/3/16 Vincent Torri
> hey
>
> in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7z, ar.exe is also named
> x86_64-w64-mingw32-gcc-ar.exe and not x86_64-w64-mingw32-ar.exe. Is it
> normal ?
>
I think it is. These seem to be related to GCC plugins, and do not appear
in my 4.6.4 build for example. When
Hi Folks!
Just some comments on my part. Nothing very useful...
On Fri, Mar 16, 2012 at 3:32 AM, Ruben Van Boxem
wrote:
> Op 16 mrt. 2012 07:17 schreef "Jim Michaels" het
> volgende:
>
>> do you submit a bug report anyway since this is in every compiler and tr1
>> examples abound? many people
hey
in x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb.7z, ar.exe is also named
x86_64-w64-mingw32-gcc-ar.exe and not x86_64-w64-mingw32-ar.exe. Is it
normal ?
Vincent Torri
--
This SF email is sponsosred by:
Try Windows Azure fr
2012/3/16 niXman :
> 2012/3/16 Kai Tietz :
>> Yes, you are actual build a cross-compiler from i686-pc-mingw32 to
>> i686-w64-mingw32. It is a cross, as triplets are different!
>>
>> 2. building binutils:
>> --target=i686-w64-mingw32
>> --enable-targets=x86_64-w64-mingw32,i686-w64-mingw
On 3/16/2012 12:47, Jim Michaels wrote:
> I know how to submit a bug report for gcc (that would be easy), but I know
> nothing about a gcc mailing list.
>
>
See gcc-help at gcc.gnu.org.
signature.asc
Description: OpenPGP digital signature
On 3/16/2012 06:16, Jim Michaels wrote:
> g++.exe: error: CreateProcess: No such file or directory
>
> I always get this error when compiling programs using
> c:\mingw-w32-bin_i686-mingw_2027\mingw\bin\g++.exe
> to compile my programs.
Don't do that, its already been ask many times.
> up to
Op 16 mrt. 2012 07:32 schreef "Jim Michaels" het
volgende:
>
> I didn't use an int. take a look.
> an int shouldn't even BE IN there. if anything, one should think you
convert to
>
> the compiler should know to convert everything at least to the return or
assign type I should think. the data typ
Op 16 mrt. 2012 07:17 schreef "Jim Michaels" het
volgende:
>
> do you submit a bug report anyway since this is in every compiler and tr1
examples abound? many people like me think you are supposed to be using
tr1 and that c++11 is just another side standard, not something that
encompasses...
C++
20 matches
Mail list logo
