[Mingw-w64-public] alloca()-Problems, a smoking gun & no resolution yet.

[Wolfgang Glas]

Hi all,

  I've been trying very hard to reduce my alloca() problems and at got stuck
with every attempt to isolate the problem.

  Finally I linked a mildly complex C-program, which crashed before using a
handcrafted Makefile and luckily I found out, that the program crashes, when I
add a bunch Window's system libraries to the linker command line. (A practice I
cowardly copied from another project years ago...)

  I've uploaded a self-contained (but not small) testcase to our weebserver 
under

  http://www.ev-i.at/tmp/mingw_hpgspdf_test.tar.gz

The makefile generates two executables: One linked just with the self-generated
DLLs and one linked with a long list of windows system libraries. The executable
linked with the windows libraries is called hpgspdffile-read-fail.exe and has a
different size than the executable hpgspdffile-read.exe linked with just the
self-generated libraries. Besides, it has the same runtime dependencies and
however it *does* crash right after alloca(), while the other one survives
flawlessly.

  The program reads a PDF-file, interprets it's internal structure and
re-serializes the file afterwards. (Should work with any normal PDF-file).

  This is my debug-session:

**
H:\wglas\CC\mingw_hpgspdf_test\bin64>gdb-w64 .\hpgspdffile-read-fail.exe
GNU gdb 6.7.50.20080109-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-mingw32"...

warning: A handler for the OS ABI "Cygwin" is not built into this configuration
of GDB.  Attempting to continue with the default i386:x86-64 settings.

(gdb) break hpgspdffile.c:1230
Breakpoint 1 at 0x40eead: file hpgspdffile.c, line 1230.
(gdb) r H:\wglas\doc\hp\bpl13205.pdf x.pdf
Starting program: H:\wglas\CC\mingw_hpgspdf_test\bin64/.\hpgspdffile-read-fail.e
xe H:\wglas\doc\hp\bpl13205.pdf x.pdf
len=28.
value=C:\Program Files (x86)\cdes.
prefix=C:\Program Files (x86)\cdes.
Opening file H:\wglas\doc\hp\bpl13205.pdf.
Reading file H:\wglas\doc\hp\bpl13205.pdf.

Breakpoint 1, hpgs_pdf_file_read_xref (pdf=0x3f7720) at hpgspdffile.c:1230
1230hpgspdffile.c: No such file or directory.
in hpgspdffile.c
(gdb) print tail_data
$1 = 0x22fda0 ""
(gdb) print &len
$2 = (size_t *) 0x22fdb0
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x07ff7fc52806 in ?? ()
(gdb) bt
#0  0x07ff7fc52806 in ?? ()
#1  0x07ff7fc4a949 in ?? ()
#2  0x0003 in ?? ()
#3  0x0003 in ?? ()
#4  0x0003 in ?? ()
#5  0x0033d627 in ?? ()
#6  0x in ?? ()
(gdb) q
The program is running.  Exit anyway? (y or n) y

H:\wglas\CC\mingw_hpgspdf_test\bin64>
**

  Explanation:

tail_data is a char-array of size 2048, which has been allocated through
alloca(), 'len' is a local variable. The problem her is, that alloca() places
tail_data 16 bytes before len, which is far less than the required 2048 bytes...

  Hopefully, this will bring us one step further in resolving this curious 
problem.

  Regards,

Wolfgang


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] alloca()-Problems, a smoking gun & no resolution yet.

[Wolfgang Glas]

Kai Tietz schrieb:
> 2009/3/15 Wolfgang Glas :
>> Hi all,
>>
>>  I've been trying very hard to reduce my alloca() problems and at got stuck
>> with every attempt to isolate the problem.
>>
>>  Finally I linked a mildly complex C-program, which crashed before using a
>> handcrafted Makefile and luckily I found out, that the program crashes, when 
>> I
>> add a bunch Window's system libraries to the linker command line. (A 
>> practice I
>> cowardly copied from another project years ago...)
>>
>>  I've uploaded a self-contained (but not small) testcase to our weebserver 
>> under
>>
>>  http://www.ev-i.at/tmp/mingw_hpgspdf_test.tar.gz
>>
>> The makefile generates two executables: One linked just with the 
>> self-generated
>> DLLs and one linked with a long list of windows system libraries. The 
>> executable
>> linked with the windows libraries is called hpgspdffile-read-fail.exe and 
>> has a
>> different size than the executable hpgspdffile-read.exe linked with just the
>> self-generated libraries. Besides, it has the same runtime dependencies and
>> however it *does* crash right after alloca(), while the other one survives
>> flawlessly.
>>
>>  The program reads a PDF-file, interprets it's internal structure and
>> re-serializes the file afterwards. (Should work with any normal PDF-file).
>>
>>  This is my debug-session:
>>
>> **
>> H:\wglas\CC\mingw_hpgspdf_test\bin64>gdb-w64 .\hpgspdffile-read-fail.exe
>> GNU gdb 6.7.50.20080109-cvs
>> Copyright (C) 2008 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later 
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-pc-mingw32"...
>>
>> warning: A handler for the OS ABI "Cygwin" is not built into this 
>> configuration
>> of GDB.  Attempting to continue with the default i386:x86-64 settings.
>>
>> (gdb) break hpgspdffile.c:1230
>> Breakpoint 1 at 0x40eead: file hpgspdffile.c, line 1230.
>> (gdb) r H:\wglas\doc\hp\bpl13205.pdf x.pdf
>> Starting program: 
>> H:\wglas\CC\mingw_hpgspdf_test\bin64/.\hpgspdffile-read-fail.e
>> xe H:\wglas\doc\hp\bpl13205.pdf x.pdf
>> len=28.
>> value=C:\Program Files (x86)\cdes.
>> prefix=C:\Program Files (x86)\cdes.
>> Opening file H:\wglas\doc\hp\bpl13205.pdf.
>> Reading file H:\wglas\doc\hp\bpl13205.pdf.
>>
>> Breakpoint 1, hpgs_pdf_file_read_xref (pdf=0x3f7720) at hpgspdffile.c:1230
>> 1230hpgspdffile.c: No such file or directory.
>>in hpgspdffile.c
>> (gdb) print tail_data
>> $1 = 0x22fda0 ""
>> (gdb) print &len
>> $2 = (size_t *) 0x22fdb0
>> (gdb) n
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x07ff7fc52806 in ?? ()
>> (gdb) bt
>> #0  0x07ff7fc52806 in ?? ()
>> #1  0x07ff7fc4a949 in ?? ()
>> #2  0x0003 in ?? ()
>> #3  0x0003 in ?? ()
>> #4  0x0003 in ?? ()
>> #5  0x0033d627 in ?? ()
>> #6  0x in ?? ()
>> (gdb) q
>> The program is running.  Exit anyway? (y or n) y
>>
>> H:\wglas\CC\mingw_hpgspdf_test\bin64>
>> **
>>
>>  Explanation:
>>
>> tail_data is a char-array of size 2048, which has been allocated through
>> alloca(), 'len' is a local variable. The problem her is, that alloca() places
>> tail_data 16 bytes before len, which is far less than the required 2048 
>> bytes...
>>
>>  Hopefully, this will bring us one step further in resolving this curious 
>> problem.
>>
>>  Regards,
>>
>>Wolfgang
>>
>>
>> --
>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
>> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
>> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
>> software that enables intelligent coding and step-through debugging.
>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
> 
> By trying to reduce this test case I stumble over the assembly produced
>  leaq30(%rbx), %rax
>  andq$-16, %rax
>  call___chkstk
> 
> so, if %rbx is zero (len == 0) this happens what you are describing.
> that tail_data is just 16 bytes away from file_len. So possibly you
> should check the result of hpgs_istream_tell(pdf->is,&file_len), if
> file_len is not equal to zero. If it is, all points to an alias issue.

Well, if I print the content of len in my debugging session, I get:

Breakpoint 1, hpgs_pdf_file_read_xref (pdf=0x3f7720) at hpgspdffile.c:1230
1230hpgspdffile.c: No such file or directory.
in hpgspdffile.c
(gdb) print len
$1 = 2048
(gdb) print &len
$2 = (size_

Re: [Mingw-w64-public] alloca()-Problems, a smoking gun & no resolution yet.

[Kai Tietz]

2009/3/15 Wolfgang Glas :
> Hi all,
>
>  I've been trying very hard to reduce my alloca() problems and at got stuck
> with every attempt to isolate the problem.
>
>  Finally I linked a mildly complex C-program, which crashed before using a
> handcrafted Makefile and luckily I found out, that the program crashes, when I
> add a bunch Window's system libraries to the linker command line. (A practice 
> I
> cowardly copied from another project years ago...)
>
>  I've uploaded a self-contained (but not small) testcase to our weebserver 
> under
>
>  http://www.ev-i.at/tmp/mingw_hpgspdf_test.tar.gz
>
> The makefile generates two executables: One linked just with the 
> self-generated
> DLLs and one linked with a long list of windows system libraries. The 
> executable
> linked with the windows libraries is called hpgspdffile-read-fail.exe and has 
> a
> different size than the executable hpgspdffile-read.exe linked with just the
> self-generated libraries. Besides, it has the same runtime dependencies and
> however it *does* crash right after alloca(), while the other one survives
> flawlessly.
>
>  The program reads a PDF-file, interprets it's internal structure and
> re-serializes the file afterwards. (Should work with any normal PDF-file).
>
>  This is my debug-session:
>
> **
> H:\wglas\CC\mingw_hpgspdf_test\bin64>gdb-w64 .\hpgspdffile-read-fail.exe
> GNU gdb 6.7.50.20080109-cvs
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-pc-mingw32"...
>
> warning: A handler for the OS ABI "Cygwin" is not built into this 
> configuration
> of GDB.  Attempting to continue with the default i386:x86-64 settings.
>
> (gdb) break hpgspdffile.c:1230
> Breakpoint 1 at 0x40eead: file hpgspdffile.c, line 1230.
> (gdb) r H:\wglas\doc\hp\bpl13205.pdf x.pdf
> Starting program: 
> H:\wglas\CC\mingw_hpgspdf_test\bin64/.\hpgspdffile-read-fail.e
> xe H:\wglas\doc\hp\bpl13205.pdf x.pdf
> len=28.
> value=C:\Program Files (x86)\cdes.
> prefix=C:\Program Files (x86)\cdes.
> Opening file H:\wglas\doc\hp\bpl13205.pdf.
> Reading file H:\wglas\doc\hp\bpl13205.pdf.
>
> Breakpoint 1, hpgs_pdf_file_read_xref (pdf=0x3f7720) at hpgspdffile.c:1230
> 1230    hpgspdffile.c: No such file or directory.
>        in hpgspdffile.c
> (gdb) print tail_data
> $1 = 0x22fda0 ""
> (gdb) print &len
> $2 = (size_t *) 0x22fdb0
> (gdb) n
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x07ff7fc52806 in ?? ()
> (gdb) bt
> #0  0x07ff7fc52806 in ?? ()
> #1  0x07ff7fc4a949 in ?? ()
> #2  0x0003 in ?? ()
> #3  0x0003 in ?? ()
> #4  0x0003 in ?? ()
> #5  0x0033d627 in ?? ()
> #6  0x in ?? ()
> (gdb) q
> The program is running.  Exit anyway? (y or n) y
>
> H:\wglas\CC\mingw_hpgspdf_test\bin64>
> **
>
>  Explanation:
>
> tail_data is a char-array of size 2048, which has been allocated through
> alloca(), 'len' is a local variable. The problem her is, that alloca() places
> tail_data 16 bytes before len, which is far less than the required 2048 
> bytes...
>
>  Hopefully, this will bring us one step further in resolving this curious 
> problem.
>
>  Regards,
>
>    Wolfgang
>
>
> --
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

By trying to reduce this test case I stumble over the assembly produced
 leaq30(%rbx), %rax
 andq$-16, %rax
 call___chkstk

so, if %rbx is zero (len == 0) this happens what you are describing.
that tail_data is just 16 bytes away from file_len. So possibly you
should check the result of hpgs_istream_tell(pdf->is,&file_len), if
file_len is not equal to zero. If it is, all points to an alias issue.

Cheers,
Kai
-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based deve

Re: [Mingw-w64-public] alloca()-Problems, a smoking gun & no resolution yet.

[Kai Tietz]

2009/3/15 Wolfgang Glas :
> Kai Tietz schrieb:
>> 2009/3/15 Wolfgang Glas :
>>> Hi all,
>>>
>>>  I've been trying very hard to reduce my alloca() problems and at got stuck
>>> with every attempt to isolate the problem.
>>>
>>>  Finally I linked a mildly complex C-program, which crashed before using a
>>> handcrafted Makefile and luckily I found out, that the program crashes, 
>>> when I
>>> add a bunch Window's system libraries to the linker command line. (A 
>>> practice I
>>> cowardly copied from another project years ago...)
>>>
>>>  I've uploaded a self-contained (but not small) testcase to our weebserver 
>>> under
>>>
>>>  http://www.ev-i.at/tmp/mingw_hpgspdf_test.tar.gz
>>>
>>> The makefile generates two executables: One linked just with the 
>>> self-generated
>>> DLLs and one linked with a long list of windows system libraries. The 
>>> executable
>>> linked with the windows libraries is called hpgspdffile-read-fail.exe and 
>>> has a
>>> different size than the executable hpgspdffile-read.exe linked with just the
>>> self-generated libraries. Besides, it has the same runtime dependencies and
>>> however it *does* crash right after alloca(), while the other one survives
>>> flawlessly.
>>>
>>>  The program reads a PDF-file, interprets it's internal structure and
>>> re-serializes the file afterwards. (Should work with any normal PDF-file).
>>>
>>>  This is my debug-session:
>>>
>>> **
>>> H:\wglas\CC\mingw_hpgspdf_test\bin64>gdb-w64 .\hpgspdffile-read-fail.exe
>>> GNU gdb 6.7.50.20080109-cvs
>>> Copyright (C) 2008 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later 
>>> 
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "x86_64-pc-mingw32"...
>>>
>>> warning: A handler for the OS ABI "Cygwin" is not built into this 
>>> configuration
>>> of GDB.  Attempting to continue with the default i386:x86-64 settings.
>>>
>>> (gdb) break hpgspdffile.c:1230
>>> Breakpoint 1 at 0x40eead: file hpgspdffile.c, line 1230.
>>> (gdb) r H:\wglas\doc\hp\bpl13205.pdf x.pdf
>>> Starting program: 
>>> H:\wglas\CC\mingw_hpgspdf_test\bin64/.\hpgspdffile-read-fail.e
>>> xe H:\wglas\doc\hp\bpl13205.pdf x.pdf
>>> len=28.
>>> value=C:\Program Files (x86)\cdes.
>>> prefix=C:\Program Files (x86)\cdes.
>>> Opening file H:\wglas\doc\hp\bpl13205.pdf.
>>> Reading file H:\wglas\doc\hp\bpl13205.pdf.
>>>
>>> Breakpoint 1, hpgs_pdf_file_read_xref (pdf=0x3f7720) at hpgspdffile.c:1230
>>> 1230    hpgspdffile.c: No such file or directory.
>>>        in hpgspdffile.c
>>> (gdb) print tail_data
>>> $1 = 0x22fda0 ""
>>> (gdb) print &len
>>> $2 = (size_t *) 0x22fdb0
>>> (gdb) n
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x07ff7fc52806 in ?? ()
>>> (gdb) bt
>>> #0  0x07ff7fc52806 in ?? ()
>>> #1  0x07ff7fc4a949 in ?? ()
>>> #2  0x0003 in ?? ()
>>> #3  0x0003 in ?? ()
>>> #4  0x0003 in ?? ()
>>> #5  0x0033d627 in ?? ()
>>> #6  0x in ?? ()
>>> (gdb) q
>>> The program is running.  Exit anyway? (y or n) y
>>>
>>> H:\wglas\CC\mingw_hpgspdf_test\bin64>
>>> **
>>>
>>>  Explanation:
>>>
>>> tail_data is a char-array of size 2048, which has been allocated through
>>> alloca(), 'len' is a local variable. The problem her is, that alloca() 
>>> places
>>> tail_data 16 bytes before len, which is far less than the required 2048 
>>> bytes...
>>>
>>>  Hopefully, this will bring us one step further in resolving this curious 
>>> problem.
>>>
>>>  Regards,
>>>
>>>    Wolfgang
>>>
>>>
>>> --
>>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
>>> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
>>> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
>>> software that enables intelligent coding and step-through debugging.
>>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
>>> ___
>>> Mingw-w64-public mailing list
>>> Mingw-w64-public@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>>
>>
>> By trying to reduce this test case I stumble over the assembly produced
>>  leaq    30(%rbx), %rax
>>  andq    $-16, %rax
>>  call    ___chkstk
>>
>> so, if %rbx is zero (len == 0) this happens what you are describing.
>> that tail_data is just 16 bytes away from file_len. So possibly you
>> should check the result of hpgs_istream_tell(pdf->is,&file_len), if
>> file_len is not equal to zero. If it is, all points to an alias issue.
>
> Well, if I print the content of len in my debugging session, I get:
>
> Breakpoint 1, hpgs_pdf_file_read_xref (pd

Re: [Mingw-w64-public] alloca()-Problems, a smoking gun & no resolution yet.

[Shaun Barlow]

Hi,

> Ok, I found the issue. Your application calls __chkstk from kernel32,
> which is pretty false. Because the MS variant just probes the stack,
> but does not allocate it as the cygwin variant. There are two possible
> ways to solve this, a) Remove the export from kernel32.def in lib64,
> or rename the method in gcc/config/i386 defined in cygwin.asm and
> referenced in i386.md

Thank you very much to Wolfgang for making the testcase, and Kai for
finding the problem :)
Applying Kai's solution a) Remove the export from kernel32.def in
lib64, to a local checkout
of the mingw-w64 crt has gotten rid of the segfaults I was
experiencing in my program

In my opinion, solution a) would be the correct course because it
matches the behaviour of both
the mingw project's export library and Microsoft own export library
(referencing __chkstk in either
and then linking to kernel32 gives an unresolved symbol). Its naming
(double underscore prefix), would
also seem to indicate that it is not intended for outside use.

It is obviously Kai's decision which route to take.

Thanks and best regards,
Shaun

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] alloca()-Problems, a smoking gun & no resolution yet.

[Kai Tietz]

2009/3/15 Shaun Barlow :
> Hi,
>
>> Ok, I found the issue. Your application calls __chkstk from kernel32,
>> which is pretty false. Because the MS variant just probes the stack,
>> but does not allocate it as the cygwin variant. There are two possible
>> ways to solve this, a) Remove the export from kernel32.def in lib64,
>> or rename the method in gcc/config/i386 defined in cygwin.asm and
>> referenced in i386.md
>
> Thank you very much to Wolfgang for making the testcase, and Kai for
> finding the problem :)
> Applying Kai's solution a) Remove the export from kernel32.def in
> lib64, to a local checkout
> of the mingw-w64 crt has gotten rid of the segfaults I was
> experiencing in my program
>
> In my opinion, solution a) would be the correct course because it
> matches the behaviour of both
> the mingw project's export library and Microsoft own export library
> (referencing __chkstk in either
> and then linking to kernel32 gives an unresolved symbol). Its naming
> (double underscore prefix), would
> also seem to indicate that it is not intended for outside use.
>
> It is obviously Kai's decision which route to take.
>
> Thanks and best regards,
> Shaun
>

Yes, this issue is a bit annoying and is ported from mingw32. I
disabled temporary the export symbol __chkstk in ntdll.def,
kernel32.def, and ntoskernl.def. So always the variant of gcc is used
and those kind of errors a prevented. But this means of course that vc
generated libraries, which are using __chkstk will fail (as the do on
32-bits).
I want to provide a change in 4.5 gcc to avoid this issue completely
and allow the co-existance of gcc's and vc's stack checking routine
for 64-bit and 32-bit by renaming the gcc's variant to __gnu_chkstk.

Fix is on mingw-w64 trunk rev.678.

Cheers,
Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] alloca()-Problems, a smoking gun & no resolution yet.

[NightStrike]

On Sun, Mar 15, 2009 at 9:41 AM, Kai Tietz  wrote:
> Fix is on mingw-w64 trunk rev.678.

Thank you very much to Kai, Wolfgang, and Shaun!

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Release policy, relationship to other mingw projects.

[Wolfgang Glas]

Hi all,

  Since we are waiting for gcc-4.4.0 being released by the SC we should take the
time a think about the way mingw-w64 will be presented to the user once it's
getting more stable. (AFAIK, it *is* already very stable)

  Making available nightly snapshots is a fine thing by now, but starting with
gcc-4.4.0 there should be an "official" mingw-w32 and mingw-w64 release with
releases notes et al.. Otherwise, package maintainers will have a hard time to
query each user which sends in a bug report for the exact snapshot he or she is
using.

  Given that mingw-w64 is a real improvement about the way the old mingw32
compiler suite is managed, it is not a replacement for all the native Windows
development tools like make, autoconf, sed, awk,... which are provided by
mingw32/msys. So I think that user, who are not interested in cross-compilation
only, might expect, that the old mingw32/msys tolls will be arranged around
latest and greatest gcc/Windows integration.

  Are there any efforts to arrange for such an integration in the near future?

  Best regards,

Wolfgang

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Release policy, relationship to other mingw projects.

[NightStrike]

On Sun, Mar 15, 2009 at 4:14 PM, Wolfgang Glas  wrote:
> Hi all,
>
>  Since we are waiting for gcc-4.4.0 being released by the SC we should take 
> the
> time a think about the way mingw-w64 will be presented to the user once it's
> getting more stable. (AFAIK, it *is* already very stable)
>
>  Making available nightly snapshots is a fine thing by now, but starting with
> gcc-4.4.0 there should be an "official" mingw-w32 and mingw-w64 release with
> releases notes et al.. Otherwise, package maintainers will have a hard time to
> query each user which sends in a bug report for the exact snapshot he or she 
> is
> using.
>
>  Given that mingw-w64 is a real improvement about the way the old mingw32
> compiler suite is managed, it is not a replacement for all the native Windows
> development tools like make, autoconf, sed, awk,... which are provided by
> mingw32/msys. So I think that user, who are not interested in 
> cross-compilation
> only, might expect, that the old mingw32/msys tolls will be arranged around
> latest and greatest gcc/Windows integration.
>
>  Are there any efforts to arrange for such an integration in the near future?

First, I created two new groups:

Toolchains targeting Win64
Toolchains targeting Win32

In each of those groups is a single release, "Automated Builds"

When gcc 4.4 is released, we will provide an actual release-tested
complete gcc 4.4-based toolchain with a specific binutils version and
a specific mingw-w64/32 version.  They will go in this area.


Now, as for a development environment, I have given thought to this.
I would like to be able to provide a complete tarball that contains a
working gnu-ish system.  The way that mingw.org packages things is too
confusing for my tastes.  However, we have not yet begun to port
things like msys, or to try compiling msys on/for Win64.  I personally
feel that the msys environment is sub-par, and if you need that much
in the way of gnu tools, you're better off going with cygwin.

So really, I guess we're open to suggestions for a definite Way Ahead
plan.  Perhaps you would like to officially join our project?

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Release policy , relationship to other mingw projects.

[Arthur Norman]

 Are there any efforts to arrange for such an integration in the near
 future?


The way that mingw.org packages things is too
confusing for my tastes.  However, we have not yet begun to port
things like msys, or to try compiling msys on/for Win64.  I personally
feel that the msys environment is sub-par, and if you need that much
in the way of gnu tools, you're better off going with cygwin.

I will stick a thought in here, but I am naturally aware that ANY move 
that consolidates mingw-w64 with other code is liable to be both a 
tecnical and a political mountain of pretty substantial magnitude, so my 
"wish" here is something I would see as a long-term ideal and probably not 
a short term easy action.


I would like to fetch one package and then have
   gcc foo.c -o foocygwin   32-bit cygwin
   gcc -mno-cygwin foo.c -o foow32  32-bit native windows
   gcc -mno-cygwin -m64 foo.c -o foow64 64-bit native windows
with all that happening effortlessly with an easy click or two in the 
options about what I fetch when I fetch the whole cygwin environment that 
I like to have so I can use all the other associated GNU and Unix-style 
tools.


So if there was any prospect that the cygwin people would be willing to 
fold your stuff into the multi-lib scheme that they already have that 
supports mingw-w32 that would give a very comfortable experience for 
people like me.


Meanwhile what you have right now is still GREAT!
Arthur--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Release policy , relationship to other mingw projects.

[NightStrike]

On Sun, Mar 15, 2009 at 4:57 PM, Arthur Norman  wrote:
>>>  Are there any efforts to arrange for such an integration in the near
>>>  future?
>>
>> The way that mingw.org packages things is too
>> confusing for my tastes.  However, we have not yet begun to port
>> things like msys, or to try compiling msys on/for Win64.  I personally
>> feel that the msys environment is sub-par, and if you need that much
>> in the way of gnu tools, you're better off going with cygwin.
>>
> I will stick a thought in here, but I am naturally aware that ANY move that
> consolidates mingw-w64 with other code is liable to be both a tecnical and a
> political mountain of pretty substantial magnitude, so my "wish" here is
> something I would see as a long-term ideal and probably not a short term
> easy action.
>
> I would like to fetch one package and then have
>   gcc foo.c -o foocygwin               32-bit cygwin
>   gcc -mno-cygwin foo.c -o foow32      32-bit native windows
>   gcc -mno-cygwin -m64 foo.c -o foow64 64-bit native windows
> with all that happening effortlessly with an easy click or two in the
> options about what I fetch when I fetch the whole cygwin environment that I
> like to have so I can use all the other associated GNU and Unix-style tools.
>
> So if there was any prospect that the cygwin people would be willing to fold
> your stuff into the multi-lib scheme that they already have that supports
> mingw-w32 that would give a very comfortable experience for people like me.
>
> Meanwhile what you have right now is still GREAT!
>            Arthur

We are working on multilib support, and have already lined up cygwin
support.  The only reason cygwin doesn't provide our toolchains yet is
that I haven't found the time to give them the files for it.  I'm
trying to keep my head above water :)

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public