• Downs <mathis.beer tu-ilmenau.de> Dec 04 2006
• Downs <mathis.beer tu-ilmenau.de> Dec 04 2006
• Carlos Santander <csantander619 gmail.com> Dec 04 2006
• Downs <mathis.beer tu-ilmenau.de> Dec 04 2006
• =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Dec 04 2006
• Downs <mathis.beer tu-ilmenau.de> Dec 04 2006
• David Friedman <dvdfrdmn users.ess-eff.net> Dec 04 2006
• Kirk McDonald <kirklin.mcdonald gmail.com> Dec 05 2006
• Dave <Dave_member pathlink.com> Dec 05 2006
• Frits van Bommel <fvbommel REMwOVExCAPSs.nl> Dec 05 2006
• Kirk McDonald <kirklin.mcdonald gmail.com> Dec 05 2006
• David Friedman <dvdfrdmn users.ess-eff.net> Dec 06 2006
• Mathieu Chouinard <mchoui e-c.qc.ca> Dec 06 2006
• David Friedman <dvdfrdmn users.ess-eff.net> Dec 06 2006
• Mathieu Chouinard <mchoui e-c.qc.ca> Dec 06 2006

Attempting to build the current rev48 gdc 0.20 branch on mingw/gcc4.0.3; 
the resulting gdc.exe is incapable of compiling even the most basic test 
files; it crashes on configure with a sigsegv in actest.d:0.
Somewhat related question; is it possible to compile gcc so that it does 
not catch segment violations internally? This "feature" makes it 
impossible for me to get stack traces of the crash in gdb (no stackdumps 
are produced either).
Alternatively, any idea what I could do to narrow the problem area down?
Thanks for ideas; greetings.

Downs wrote:
 Attempting to build the current rev48 gdc 0.20 branch on mingw/gcc4.0.3; 
 the resulting gdc.exe is incapable of compiling even the most basic test 
 files; it crashes on configure with a sigsegv in actest.d:0.
 Somewhat related question; is it possible to compile gcc so that it does 
 not catch segment violations internally? This "feature" makes it 
 impossible for me to get stack traces of the crash in gdb (no stackdumps 
 are produced either).
 Alternatively, any idea what I could do to narrow the problem area down?
 Thanks for ideas; greetings.


Oh, btw; my configure flags were --enable-languages=c,d 
--prefix=/MinGW/gdc --enable-threads=win32 --disable-nls 
--disable-win32-registry --disable-shared --disable-bootstrap. CFLAGS 
was -O0 -pipe, CXXFLAGS dito, LDFLAGS set to empty, DFLAGS not set.

Downs escribió:
 Attempting to build the current rev48 gdc 0.20 branch on mingw/gcc4.0.3; 
 the resulting gdc.exe is incapable of compiling even the most basic test 
 files; it crashes on configure with a sigsegv in actest.d:0.
 Somewhat related question; is it possible to compile gcc so that it does 
 not catch segment violations internally? This "feature" makes it 
 impossible for me to get stack traces of the crash in gdb (no stackdumps 
 are produced either).
 Alternatively, any idea what I could do to narrow the problem area down?
 Thanks for ideas; greetings.


The ChangeLog right now says "More 0.176 merges", so I would consider the 
compiler unstable.

-- 
Carlos Santander Bernal

Carlos Santander wrote:
 Downs escribió:
 Attempting to build the current rev48 gdc 0.20 branch on 
 mingw/gcc4.0.3; the resulting gdc.exe is incapable of compiling even 
 the most basic test files; it crashes on configure with a sigsegv in 
 actest.d:0.
 Somewhat related question; is it possible to compile gcc so that it 
 does not catch segment violations internally? This "feature" makes it 
 impossible for me to get stack traces of the crash in gdb (no 
 stackdumps are produced either).
 Alternatively, any idea what I could do to narrow the problem area down?
 Thanks for ideas; greetings.


 The ChangeLog right now says "More 0.176 merges", so I would consider 
 the compiler unstable.
 


I was under the assumption code had to be somewhat stable-y to be 
checked into svn. Good point though; I hadn't considered that.
  Still, the current version of the compiler fails on a _trivial_ 
example; so I still think I was justified in pointing it out (especially 
considering the problem seems to be exclusive to win32 (somebody is 
using rev48 under macos without problems (I think)) and, there not being 
that many gdcwin users, it could well have gone unnoticed (on that note, 
does anybody know if the gdc maintainer does test builds on win32?))
Greetings

Downs wrote:

 does anybody know if the gdc maintainer does test builds on win32?


I believe that David Friedman makes GDC binaries for MinGW and Cygwin,
at least there were for the GDC 0.19 release so it might be for 0.20 ?

--anders

Anders F Björklund wrote:
 Downs wrote:
 
 does anybody know if the gdc maintainer does test builds on win32?


 I believe that David Friedman makes GDC binaries for MinGW and Cygwin,
 at least there were for the GDC 0.19 release so it might be for 0.20 ?
 
 --anders


Okay, good to know. Thanks :)

Downs wrote:
 Carlos Santander wrote:
 
 Downs escribió:

 Attempting to build the current rev48 gdc 0.20 branch on 
 mingw/gcc4.0.3; the resulting gdc.exe is incapable of compiling even 
 the most basic test files; it crashes on configure with a sigsegv in 
 actest.d:0.
 Somewhat related question; is it possible to compile gcc so that it 
 does not catch segment violations internally? This "feature" makes it 
 impossible for me to get stack traces of the crash in gdb (no 
 stackdumps are produced either).
 Alternatively, any idea what I could do to narrow the problem area down?
 Thanks for ideas; greetings.



 The ChangeLog right now says "More 0.176 merges", so I would consider 
 the compiler unstable.


 I was under the assumption code had to be somewhat stable-y to be 
 checked into svn. Good point though; I hadn't considered that.
  Still, the current version of the compiler fails on a _trivial_ 
 example; so I still think I was justified in pointing it out (especially 
 considering the problem seems to be exclusive to win32 (somebody is 
 using rev48 under macos without problems (I think)) and, there not being 
 that many gdcwin users, it could well have gone unnoticed (on that note, 
 does anybody know if the gdc maintainer does test builds on win32?))
 Greetings


The trunk will be stable, but don't expect the same of a "-dev" branch. 
  One thing I'm trying to do is put the raw merge of new DMD version in 
a separate commit from any further modifications to the DMD code that 
are needed to get it working with GDC.  The code is no even going to 
compile after some of those merges.  That said, I want to keep the dev 
code fairly stable.

I usually only build for my current development platofrm (currently GCC 
4.0.3 on MacOS Intel) unless there have been changes that I think might 
cause problems.  When I start to put a release together, I will run 
regression tests on all of the other targets.

So... I was not aware of this problem.  Thanks for pointing it out.  I 
realize people are building out of the dev branch because there has not 
been a release for so long... I will try to get this fixed soon.

David

David Friedman wrote:
 So... I was not aware of this problem.  Thanks for pointing it out.  I 
 realize people are building out of the dev branch because there has not 
 been a release for so long... I will try to get this fixed soon.


I am eagerly awaiting a stable release of GDC that is caught up to DMD 
0.176. As far as I can tell, this will allow Pyd to compile on Linux, 
which will allow me to declare an actual release of the library. My hope 
is that this will then attract some of the Python crowd to D.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org

Kirk McDonald wrote:
 David Friedman wrote:
 So... I was not aware of this problem.  Thanks for pointing it out.  I 
 realize people are building out of the dev branch because there has 
 not been a release for so long... I will try to get this fixed soon.


 I am eagerly awaiting a stable release of GDC that is caught up to DMD 
 0.176. As far as I can tell, this will allow Pyd to compile on Linux, 
 which will allow me to declare an actual release of the library. My hope 
 is that this will then attract some of the Python crowd to D.
 


Just curious - will DMD 0.176 not work for this, or do you just prefer GDC for
that platform?

Thanks.

Dave wrote:
 Kirk McDonald wrote:
 David Friedman wrote:
 So... I was not aware of this problem.  Thanks for pointing it out.  
 I realize people are building out of the dev branch because there has 
 not been a release for so long... I will try to get this fixed soon.


 I am eagerly awaiting a stable release of GDC that is caught up to DMD 
 0.176. As far as I can tell, this will allow Pyd to compile on Linux, 
 which will allow me to declare an actual release of the library. My 
 hope is that this will then attract some of the Python crowd to D.


 Just curious - will DMD 0.176 not work for this, or do you just prefer 
 GDC for that platform?


I think it's because to use Pyd you need to compile as a shared library, 
which DMD doesn't support on Linux. Couldn't find an explicit statement 
about this on the site, though.

Dave wrote:
 Kirk McDonald wrote:
 David Friedman wrote:
 So... I was not aware of this problem.  Thanks for pointing it out.  
 I realize people are building out of the dev branch because there has 
 not been a release for so long... I will try to get this fixed soon.


 I am eagerly awaiting a stable release of GDC that is caught up to DMD 
 0.176. As far as I can tell, this will allow Pyd to compile on Linux, 
 which will allow me to declare an actual release of the library. My 
 hope is that this will then attract some of the Python crowd to D.


 Just curious - will DMD 0.176 not work for this, or do you just prefer 
 GDC for that platform?
 
 Thanks.


The last time I checked, DMD could not compile working .so files on Linux.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org

Downs wrote:
 Attempting to build the current rev48 gdc 0.20 branch on mingw/gcc4.0.3; 
 the resulting gdc.exe is incapable of compiling even the most basic test 
 files; it crashes on configure with a sigsegv in actest.d:0.
 Somewhat related question; is it possible to compile gcc so that it does 
 not catch segment violations internally? This "feature" makes it 
 impossible for me to get stack traces of the crash in gdb (no stackdumps 
 are produced either).
 Alternatively, any idea what I could do to narrow the problem area down?
 Thanks for ideas; greetings.


This problem has been fixed in subversion rev.50.  MinGW uses msvcrt 
which does not have a C99-compatible printf.  Thus, all of the new 
'%z..' and '%j...' formats are ignored.  Something like printf("%zu %s", 
42, "M$") crashes.

Re: gdb.  It should catch segfaults.  Were you debugging gdc.exe?  The 
actual compiler is cc1d.exe.

David

Downs wrote:

 Attempting to build the current rev48 gdc 0.20 branch on mingw/gcc4.0.3;
 the resulting gdc.exe is incapable of compiling even the most basic test
 files; it crashes on configure with a sigsegv in actest.d:0.
 Somewhat related question; is it possible to compile gcc so that it does
 not catch segment violations internally? This "feature" makes it
 impossible for me to get stack traces of the crash in gdb (no stackdumps
 are produced either).
 Alternatively, any idea what I could do to narrow the problem area down?
 Thanks for ideas; greetings.


Mathieu
-- 
Tip of the day:
The Windows 95 CD-ROM makes an excellent skeet shoot target.

Mathieu Chouinard wrote:
 Downs wrote:
 
 
Attempting to build the current rev48 gdc 0.20 branch on mingw/gcc4.0.3;
the resulting gdc.exe is incapable of compiling even the most basic test
files; it crashes on configure with a sigsegv in actest.d:0.
Somewhat related question; is it possible to compile gcc so that it does
not catch segment violations internally? This "feature" makes it
impossible for me to get stack traces of the crash in gdb (no stackdumps
are produced either).
Alternatively, any idea what I could do to narrow the problem area down?
Thanks for ideas; greetings.


 Will this developement branch have any support for gcc 4.1.x?
 Mathieu


No, my goal for the next release is just fix critical bugs and to get 
the DMD 0.176 merge stable.

David

David Friedman wrote:

 Mathieu Chouinard wrote:
 Downs wrote:
 
 
Attempting to build the current rev48 gdc 0.20 branch on mingw/gcc4.0.3;
the resulting gdc.exe is incapable of compiling even the most basic test
files; it crashes on configure with a sigsegv in actest.d:0.
Somewhat related question; is it possible to compile gcc so that it does
not catch segment violations internally? This "feature" makes it
impossible for me to get stack traces of the crash in gdb (no stackdumps
are produced either).
Alternatively, any idea what I could do to narrow the problem area down?
Thanks for ideas; greetings.


 Will this developement branch have any support for gcc 4.1.x?
 Mathieu


 No, my goal for the next release is just fix critical bugs and to get
 the DMD 0.176 merge stable.
 
 David


Mathieu
-- 
One possible reason that things aren't going according to plan
is that there never was a plan in the first place.