Thread: 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@dunslane.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@dunslane.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@sss.pgh.pa.us> wrote: > Andrew Dunstan <andrew@dunslane.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@sss.pgh.pa.us> wrote: >> Andrew Dunstan<andrew@dunslane.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
Attachment
On Sun, Dec 26, 2010 at 01:10, Andrew Dunstan <andrew@dunslane.net> wrote: > > > On 12/20/2010 01:25 PM, Magnus Hagander wrote: >> >> On Mon, Dec 20, 2010 at 19:24, Tom Lane<tgl@sss.pgh.pa.us> wrote: >>> >>> Andrew Dunstan<andrew@dunslane.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@dunslane.net> wrote: >> >> On 12/20/2010 01:25 PM, Magnus Hagander wrote: >>> On Mon, Dec 20, 2010 at 19:24, Tom Lane<tgl@sss.pgh.pa.us> wrote: >>>> Andrew Dunstan<andrew@dunslane.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