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.