On Thu, 6 May 2010, AA wrote:
> Hello,
>
> I must port a Linux application to Windows.
> Unfortunately my code uses the LP64 (standard Unix/Linux) convention
> instead of LLP64 (MS VC) and it's a bit difficult to modify all the C code.
>
> The difference between the two convention is the lenght of
AA wrote:
> Hello,
>
> I must port a Linux application to Windows.
> Unfortunately my code uses the LP64 (standard Unix/Linux) convention
> instead of LLP64 (MS VC) and it's a bit difficult to modify all the C code.
>
> The difference between the two convention is the lenght of long (integer) :
On Thu, May 6, 2010 at 7:06 AM, t66...@gmail.com wrote:
> Hello:
> After I have built a cross compiler + native one, of gcc-4_5-branch +
> binutils-cvs, in previous build problem of the gcc-releases having
> leading underscore.
>
> There is a problem of how mingw-w64-svn winsock2.h is currently im
Hello,
I must port a Linux application to Windows.
Unfortunately my code uses the LP64 (standard Unix/Linux) convention
instead of LLP64 (MS VC) and it's a bit difficult to modify all the C code.
The difference between the two convention is the lenght of long (integer) :
LLP64 : the long is 32 b
Hello:
After I have built a cross compiler + native one, of gcc-4_5-branch +
binutils-cvs, in previous build problem of the gcc-releases having
leading underscore.
There is a problem of how mingw-w64-svn winsock2.h is currently implemented.
The libcddb compile fails at:
cddb_track.o
In file incl
On 5/6/2010 08:12, Jarrod Chesney wrote:
>> pavel wrote:
>>
>>> On Tue, 2010-05-04 at 13:26 +0200, pavel wrote:
why the latest release links the programs with the
"libgcc_s_sjsj-1.dll"? Is it possible to avoid that?
>>>
>>> I have figured this out already.
>>
>> Just for the record,
I'm on the list. Please reply to the list.
Jarrod Chesney wrote:
> Also to note : With out this you will have issues when exceptions are
> thrown across DLL boundaries.
Thats really only an issue for C++ code isn't it? Does it affect C
code as well?
Erik
--
---
On 06/05/2010, at 10:26 AM, JonY wrote:
> On 5/6/2010 08:12, Jarrod Chesney wrote:
>>> pavel wrote:
>>>
On Tue, 2010-05-04 at 13:26 +0200, pavel wrote:
>
> why the latest release links the programs with the
> "libgcc_s_sjsj-1.dll"? Is it possible to avoid that?
I have
> pavel wrote:
>
>> On Tue, 2010-05-04 at 13:26 +0200, pavel wrote:
>>>
>>> why the latest release links the programs with the
>>> "libgcc_s_sjsj-1.dll"? Is it possible to avoid that?
>>
>> I have figured this out already.
>
> Just for the record, how do you avoid this?
You use --enable-static
pavel wrote:
> On Tue, 2010-05-04 at 13:26 +0200, pavel wrote:
> >
> > why the latest release links the programs with the
> > "libgcc_s_sjsj-1.dll"? Is it possible to avoid that?
>
> I have figured this out already.
Just for the record, how do you avoid this?
Cheers,
Erik
--
-
On 5 May 2010 18:09, Ozkan Sezer wrote:
> On Wed, May 5, 2010 at 8:03 PM, Dmitrijs Ledkovs
> wrote:
>> On 5 May 2010 16:56, Ozkan Sezer wrote:
> Already tested that before sending. Compiled using my own x86-linux->
> w64 toolchain, the result runs just fine on w64. (why should it fail?)
On Wed, May 5, 2010 at 8:03 PM, Dmitrijs Ledkovs
wrote:
> On 5 May 2010 16:56, Ozkan Sezer wrote:
Already tested that before sending. Compiled using my own x86-linux->
w64 toolchain, the result runs just fine on w64. (why should it fail?)
>>>
>>> Because debian smarty pants script
On 5 May 2010 16:56, Ozkan Sezer wrote:
>>> Already tested that before sending. Compiled using my own x86-linux->
>>> w64 toolchain, the result runs just fine on w64. (why should it fail?)
>>>
>>
>> Because debian smarty pants script for detection of "code assumes
>> pointer size = size of int is
On 2010-05-05 17:50, Ozkan Sezer wrote:
> On Wed, May 5, 2010 at 6:42 PM, Dmitrijs Ledkovs
> wrote:
>> On 5 May 2010 16:31, Ozkan Sezer wrote:
>>> On Wed, May 5, 2010 at 6:22 PM, Wolfgang Glas wrote:
On 2010-05-05 16:49, Ozkan Sezer wrote:
>>> Can you please write s simple Fortran progr
>> Already tested that before sending. Compiled using my own x86-linux->
>> w64 toolchain, the result runs just fine on w64. (why should it fail?)
>>
>
> Because debian smarty pants script for detection of "code assumes
> pointer size = size of int is wrong" =)
Can you tell me exactly which file/l
On 5 May 2010 16:50, Ozkan Sezer wrote:
> On Wed, May 5, 2010 at 6:42 PM, Dmitrijs Ledkovs
> wrote:
>> On 5 May 2010 16:31, Ozkan Sezer wrote:
>>> On Wed, May 5, 2010 at 6:22 PM, Wolfgang Glas wrote:
On 2010-05-05 16:49, Ozkan Sezer wrote:
>>> Can you please write s simple Fortran prog
On Wed, May 5, 2010 at 6:42 PM, Dmitrijs Ledkovs
wrote:
> On 5 May 2010 16:31, Ozkan Sezer wrote:
>> On Wed, May 5, 2010 at 6:22 PM, Wolfgang Glas wrote:
>>> On 2010-05-05 16:49, Ozkan Sezer wrote:
>> Can you please write s simple Fortran programm which will call this:
>>
>> 60 /*
On 5 May 2010 16:31, Ozkan Sezer wrote:
> On Wed, May 5, 2010 at 6:22 PM, Wolfgang Glas wrote:
>> On 2010-05-05 16:49, Ozkan Sezer wrote:
> Can you please write s simple Fortran programm which will call this:
>
> 60 /* GETLOG (LOGIN), g77 intrinsic for retrieving the login name for
On Wed, May 5, 2010 at 6:22 PM, Wolfgang Glas wrote:
> On 2010-05-05 16:49, Ozkan Sezer wrote:
Can you please write s simple Fortran programm which will call this:
60 /* GETLOG (LOGIN), g77 intrinsic for retrieving the login name for the
61 process.
62 CHARACTE
On 2010-05-05 16:49, Ozkan Sezer wrote:
>>> Can you please write s simple Fortran programm which will call this:
>>>
>>> 60 /* GETLOG (LOGIN), g77 intrinsic for retrieving the login name for the
>>> 61process.
>>> 62CHARACTER(len=*), INTENT(OUT) :: LOGIN */
>>
> Your getlog.f prints
>> Can you please write s simple Fortran programm which will call this:
>>
>> 60 /* GETLOG (LOGIN), g77 intrinsic for retrieving the login name for the
>> 61 process.
>> 62 CHARACTER(len=*), INTENT(OUT) :: LOGIN */
>
> Program is attached, however it produces the same result on ubuntu
Hi Дмитрий (Dmitrijs),
Thank for adding me to the ming-w64 ubuntu group ;-)
On 2010-05-05 11:22, Dmitrijs Ledkovs wrote:
> On 4 May 2010 22:07, Wolfgang Glas wrote:
>> On 2010-05-04 17:34, Dmitrijs Ledkovs wrote:
>>> On 4 May 2010 15:25, Wolfgang Glas wrote:
On 2010-05-04 15:48, Dmitrijs
On 4 May 2010 22:07, Wolfgang Glas wrote:
> On 2010-05-04 17:34, Dmitrijs Ledkovs wrote:
>> On 4 May 2010 15:25, Wolfgang Glas wrote:
>>> On 2010-05-04 15:48, Dmitrijs Ledkovs wrote:
On 4 May 2010 13:37, Wolfgang Glas wrote:
>
> Summing up, suach an official mingw-w64-gcc-4.4.4 rel
Just to express my happiness. The WebKit part has been merged, so every part
of Qt works now.
To compile Qt 4.7 (development version!):
Get sources from eg qt.gitorious.org/qt/qt/4.7
Get mingw-w64 from here: mingw-w64.sourceforge.net
Make sure the \bin folder has a copy of gmake named "mingw32-mak
24 matches
Mail list logo
