Re: MingW and MiniDumps

Seems at least one mingw machine is missing the definitions for
minidumps. It does seem to have the header (dbghelp.h) that's
required, but with incomplete contents?

Can someone who has a working mingw environment look for the
definitions? See
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=narwhal&dt=2010-12-19%2017%3A00%3A01
for ref on what's missing.

If they're not defined on mingw, I'm inclined to just not bother
building the crashdump functionality at all on mingw. It's likely less
useful there since mingw doesn't use windows compatible symbol tables,
but it might still be a bit useful due to our "export everything"
approach.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On 12/19/2010 12:23 PM, Magnus Hagander wrote:
> Seems at least one mingw machine is missing the definitions for
> minidumps. It does seem to have the header (dbghelp.h) that's
> required, but with incomplete contents?
>
> Can someone who has a working mingw environment look for the
> definitions? See
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=narwhal&dt=2010-12-19%2017%3A00%3A01
> for ref on what's missing.
>
> If they're not defined on mingw, I'm inclined to just not bother
> building the crashdump functionality at all on mingw. It's likely less
> useful there since mingw doesn't use windows compatible symbol tables,
> but it might still be a bit useful due to our "export everything"
> approach.

I can't find either the header or the symbols.

cheers

andrew

On Sun, Dec 19, 2010 at 20:58, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> On 12/19/2010 12:23 PM, Magnus Hagander wrote:
>>
>> Seems at least one mingw machine is missing the definitions for
>> minidumps. It does seem to have the header (dbghelp.h) that's
>> required, but with incomplete contents?
>>
>> Can someone who has a working mingw environment look for the
>> definitions? See
>>
>> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=narwhal&dt=2010-12-19%2017%3A00%3A01
>> for ref on what's missing.
>>
>> If they're not defined on mingw, I'm inclined to just not bother
>> building the crashdump functionality at all on mingw. It's likely less
>> useful there since mingw doesn't use windows compatible symbol tables,
>> but it might still be a bit useful due to our "export everything"
>> approach.
>
> I can't find either the header or the symbols.

That's weird - from what I can tell, at least narwahl isn't
complaining about a missing include file, just the undefined symbols.
Different versions of mingw perhaps?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On 12/19/2010 03:09 PM, Magnus Hagander wrote:
>>
>> I can't find either the header or the symbols.
> That's weird - from what I can tell, at least narwahl isn't
> complaining about a missing include file, just the undefined symbols.
> Different versions of mingw perhaps?
>

Maybe. I have no idea where narwhal got its version of dbghelp.h. I
copied the file from the SDK directory to mingw's include directory and
the build then ran perfectly. I think therefore the right thing is to
have a configure test for the file and for MINIDUMP_TYPE on win32, and
only build in crashdump if it passes those tests.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Maybe. I have no idea where narwhal got its version of dbghelp.h. I
> copied the file from the SDK directory to mingw's include directory and
> the build then ran perfectly. I think therefore the right thing is to
> have a configure test for the file and for MINIDUMP_TYPE on win32, and
> only build in crashdump if it passes those tests.

mmm ... how ya gonna do that on the MSVC side of things?

regards, tom lane

On Mon, Dec 20, 2010 at 19:24, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> Maybe. I have no idea where narwhal got its version of dbghelp.h. I
>> copied the file from the SDK directory to mingw's include directory and
>> the build then ran perfectly. I think therefore the right thing is to
>> have a configure test for the file and for MINIDUMP_TYPE on win32, and
>> only build in crashdump if it passes those tests.

+1.

> mmm ... how ya gonna do that on the MSVC side of things?

MSVC always has the Platform SDK. So it has the required headers.

There was one symbol missing from an older version of the platform
sdk, but it's not really one we need...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On 12/20/2010 01:25 PM, Magnus Hagander wrote:
> On Mon, Dec 20, 2010 at 19:24, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
>>> Maybe. I have no idea where narwhal got its version of dbghelp.h. I
>>> copied the file from the SDK directory to mingw's include directory and
>>> the build then ran perfectly. I think therefore the right thing is to
>>> have a configure test for the file and for MINIDUMP_TYPE on win32, and
>>> only build in crashdump if it passes those tests.
> +1.
>
>

Suggested patch attached.

cheers

andrew

On Sun, Dec 26, 2010 at 01:10, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> On 12/20/2010 01:25 PM, Magnus Hagander wrote:
>>
>> On Mon, Dec 20, 2010 at 19:24, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us>  wrote:
>>>
>>> Andrew Dunstan<andrew(at)dunslane(dot)net>  writes:
>>>>
>>>> Maybe. I have no idea where narwhal got its version of dbghelp.h. I
>>>> copied the file from the SDK directory to mingw's include directory and
>>>> the build then ran perfectly. I think therefore the right thing is to
>>>> have a configure test for the file and for MINIDUMP_TYPE on win32, and
>>>> only build in crashdump if it passes those tests.
>>
>> +1.
>>
>>
>
> Suggested patch attached.

I wonder if we need to actually care about which enum values are
actually within the symbol. But let's try it this way first and see
what the buildfarm has to say about that.

Doesn't this break the msvc build? (Sorry, don't have one up to test
right now).. You moved the crashdump.o file to a separate line from
OBS, which I believe will make the msvc build system loose it. So
you'll have to explicitly add it back on msvc, in Mkvcbuild.pm.

Other than that, looks good.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On 12/26/2010 04:35 AM, Magnus Hagander wrote:
> On Sun, Dec 26, 2010 at 01:10, Andrew Dunstan<andrew(at)dunslane(dot)net> wrote:
>>
>> On 12/20/2010 01:25 PM, Magnus Hagander wrote:
>>> On Mon, Dec 20, 2010 at 19:24, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
>>>>> Maybe. I have no idea where narwhal got its version of dbghelp.h. I
>>>>> copied the file from the SDK directory to mingw's include directory and
>>>>> the build then ran perfectly. I think therefore the right thing is to
>>>>> have a configure test for the file and for MINIDUMP_TYPE on win32, and
>>>>> only build in crashdump if it passes those tests.
>>> +1.
>>>
>>>
>> Suggested patch attached.
> I wonder if we need to actually care about which enum values are
> actually within the symbol. But let's try it this way first and see
> what the buildfarm has to say about that.
>
> Doesn't this break the msvc build? (Sorry, don't have one up to test
> right now).. You moved the crashdump.o file to a separate line from
> OBS, which I believe will make the msvc build system loose it. So
> you'll have to explicitly add it back on msvc, in Mkvcbuild.pm.

I think it will actually be OK. If not I'll fix it.

> Other than that, looks good.
>

OK. applied.

cheers

andrew