On 9/9/2010 12:36, Nils Woetzel wrote:
>>> cd gcc-4.5.1-build
>>> ln -s /mypath/x86_64-w64-mingw32 ./mingw
>>>
>>> assuming, that you are building/configuring gcc in the folder
>>> gcc-4.5.1-build - otherwise whatever path
>>> I guess the howto assumes that /mypath is also the configure and build
>
On Thu, Sep 9, 2010 at 12:09 PM, John E. / TDM wrote:
> On 9/8/2010 9:43 PM, Xiaofan Chen wrote:
>> I see. This makes sense. However, TDM64 does use "gcc", under
>> 32bit or 64bit Windows. I think it is a cross-compiler as well.
>
> No, TDM64 GCC is a native x86_64-w64-mingw32 compiler -- in othe
>> cd gcc-4.5.1-build
>> ln -s /mypath/x86_64-w64-mingw32 ./mingw
>>
>> assuming, that you are building/configuring gcc in the folder
>> gcc-4.5.1-build - otherwise whatever path
>> I guess the howto assumes that /mypath is also the configure and build
>> directory, than you do not have that proble
On 9/8/2010 9:43 PM, Xiaofan Chen wrote:
> I see. This makes sense. However, TDM64 does use "gcc", under
> 32bit or 64bit Windows. I think it is a cross-compiler as well.
No, TDM64 GCC is a native x86_64-w64-mingw32 compiler -- in other words,
it runs under Windows 64-bit and targets (by defaul
On Thu, Sep 9, 2010 at 11:11 AM, JonY wrote:
>> Can this be fixed and lib64 directory be removed?
>>
> If you have moved them and lib64 becomes empty, yes.
Move them to lib, right? What are the use of those files?
>> Another thing, typically other MinGW-w64 binaries for Windows
>> will have gcc
Maybe gendef can help you if you have a dll.
On Wed, Sep 8, 2010 at 9:29 PM, Chris Sutcliffe wrote:
> Hi All,
>
> I'm trying to create a python enabled gdb for 64-bit MinGW-w64.
> Unfortunately the x64 python distribution for Windows does not include
> a libpython27.a and as such I was hoping to
On 9/9/2010 08:00, Xiaofan Chen wrote:
> On Tue, Sep 7, 2010 at 8:00 PM, Xiaofan Chen wrote:
>> On Tue, Sep 7, 2010 at 10:36 AM, JonY wrote:
>>>
>>> Ok, to clear everything up, for non-multilib 4.6, you should only have
>>> "lib", "lib64" only if you have non-multilib 4.5.
>>>
>>
>> It seems the
On 9/9/2010 06:14, Danny Smith wrote:
>> may bite. Unless libstdc++ basic_string class is marked as dllimport,
>> _S_empty_rep is effectively hidden and different modules will have
>> different addresses for _S_empty_rep.
>
>
>> This can be fised by compiling libstdc++
>>
>
>
> This can be fi
On 9/9/2010 04:27, Mario Emmenlauer wrote:
>
> Hi JonY,
>
> On 09/07/2010 12:03 PM, JonY wrote:
>> On 9/7/2010 15:20, Mario Emmenlauer wrote:
On 9/7/2010 01:34, Mario Emmenlauer wrote:
> On 09/06/2010 04:52 PM, JonY wrote:
>> On 9/6/2010 19:50, Mario Emmenlauer wrote:
On 9/6/2
Hi All,
I'm trying to create a python enabled gdb for 64-bit MinGW-w64.
Unfortunately the x64 python distribution for Windows does not include
a libpython27.a and as such I was hoping to create one from the
python27.lib file it does supply. Normally I'd use reimp in the
mingw.org world, but can't
On Tue, Sep 7, 2010 at 8:00 PM, Xiaofan Chen wrote:
> On Tue, Sep 7, 2010 at 10:36 AM, JonY wrote:
>>
>> Ok, to clear everything up, for non-multilib 4.6, you should only have
>> "lib", "lib64" only if you have non-multilib 4.5.
>>
>
> It seems the latest automatic build version still has the sam
On Thu, Sep 9, 2010 at 3:53 AM, Ozkan Sezer wrote:
> I made some progress: I checked out branches/libusb-testing/ from
> your libusb-win32 svn, I tried compiling src/driver/abort_endpoint.c
> and it succeeded with the following changes:
>
> 1. one thing causing the mess was the windows.h include
> may bite. Unless libstdc++ basic_string class is marked as dllimport,
> _S_empty_rep is effectively hidden and different modules will have
> different addresses for _S_empty_rep.
> This can be fised by compiling libstdc++
>
This can be fixed by compiling libstdc++ with --enable-fully-dynam
On Thu, Sep 9, 2010 at 4:25 AM, JonY wrote:
> On 9/8/2010 23:34, Mario Emmenlauer wrote:
>> Please excuse my ignorance, I just read the subject and not the details
>> but I would like to note that throwing/catching exceptions between DSO's
>> (dynamically linked objects) can be very tricky with gc
Hi JonY,
On 09/07/2010 12:03 PM, JonY wrote:
> On 9/7/2010 15:20, Mario Emmenlauer wrote:
>>> On 9/7/2010 01:34, Mario Emmenlauer wrote:
On 09/06/2010 04:52 PM, JonY wrote:
> On 9/6/2010 19:50, Mario Emmenlauer wrote:
>>> On 9/6/2010 15:52, Mario Emmenlauer wrote:
I'm the or
On Wed, Sep 8, 2010 at 5:12 PM, Xiaofan Chen wrote:
> On Wed, Sep 8, 2010 at 1:22 PM, Xiaofan Chen wrote:
>> On Wed, Sep 8, 2010 at 1:16 PM, Ozkan Sezer wrote:
>>
>>> See
>>> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/ddk_test/
>>> I'd say take
>>> http://mingw-w64.svn.s
gw32/4.4.5/../../../../x86_64-w64-mingw32/include/winnt.h:2413:
>> note: previous declaration of 'RtlVirtualUnwind' was here
>>
>>
>> Full log at
>> http://launchpadlibrarian.net/55185586/buildlog_ubuntu-lucid-amd64.w64-toolchain_1.0b%2B2010090
On Wed, Sep 08, 2010 at 11:22:20PM +0800, JonY wrote:
> On 9/8/2010 21:26, Sébastien Villemot wrote:
> >Some extra information on the problem that I described in my previous post,
> >and
> >which I suspect to be a bug in MinGW-w64 for 64-bit platform.
> >
> >I attach a sample testcase, which I com
On 9/8/2010 23:34, Mario Emmenlauer wrote:
>
> Hi,
>
>> On 9/8/2010 21:26, Sébastien Villemot wrote:
>>> Hi,
>>>
>>> Some extra information on the problem that I described in my previous
>>> post, and
>>> which I suspect to be a bug in MinGW-w64 for 64-bit platform.
>>>
>>> I attach a sample testc
Hi,
> On 9/8/2010 21:26, Sébastien Villemot wrote:
>> Hi,
>>
>> Some extra information on the problem that I described in my previous
>> post, and
>> which I suspect to be a bug in MinGW-w64 for 64-bit platform.
>>
>> I attach a sample testcase, which I compile with:
>>
>> x86_64-w64-mingw32-gcc
On 9/8/2010 21:26, Sébastien Villemot wrote:
> Hi,
>
> Some extra information on the problem that I described in my previous post,
> and
> which I suspect to be a bug in MinGW-w64 for 64-bit platform.
>
> I attach a sample testcase, which I compile with:
>
> x86_64-w64-mingw32-gcc -g -O2 -fexcepti
On Wed, Sep 8, 2010 at 1:22 PM, Xiaofan Chen wrote:
> On Wed, Sep 8, 2010 at 1:16 PM, Ozkan Sezer wrote:
>
>> See
>> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/ddk_test/
>> I'd say take
>> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/ddk_test/include
Hi,
Some extra information on the problem that I described in my previous post, and
which I suspect to be a bug in MinGW-w64 for 64-bit platform.
I attach a sample testcase, which I compile with:
x86_64-w64-mingw32-gcc -g -O2 -fexceptions -Wall -shared
-I~/MATLAB/extern/include mextest.c -o mext
here
>
>
> Full log at
> http://launchpadlibrarian.net/55185586/buildlog_ubuntu-lucid-amd64.w64-toolchain_1.0b%2B201009080043-0w2176g93802b21973p11~lucid1_FAILEDTOBUILD.txt.gz
>
> Time 201009080043
> Mingw-w64 trunk bzr 2176 = svn trunk 3526
> Gcc 4.4 branch @ commit from ibo
John E wrote:
>I am able to build wxWidgets 2.9.1 and wxWidgets SVN trunk with a single
>one-line patch under TDM64, and would not have released it if I couldn't.
>However, I always use makefile.gcc from the Windows shell, not MSYS.
>At any rate, the only way to prove to me that there is a TDM-G
p11~lucid1_FAILEDTOBUILD.txt.gz
Time 201009080043
Mingw-w64 trunk bzr 2176 = svn trunk 3526
Gcc 4.4 branch @ commit from ibolton (daily dump 20100908)
Binutils daily dump @ 2010908
--
This SF.net Dev2Dev email is sponsor
26 matches
Mail list logo
