Magnus Hagander wrote: >>> Hmm. This was even worse than I thought :-( >>> >>> I got it building most of the way by following Andrews suggestion and >>> greating a pgoff_t, just to check it out. That done, it seems that mingw >>> doesn't include these 64-bit functions in their import library *at all*. >>> That gives us basically two options that I can see, to proceed: >>> >>> 1) Set up pg_dump* to dynamically load these functions from msvcrt.dll >>> at startup. This will require a different codepath from the MSVC build >>> of course, since Microsoft have been shipping these functions in their >>> libraries since NT4. Should work, but nor particularly pretty. >>> >>> 2) Just say that the mingw compiled versions of pg_dump* can't deal with >>> 2Gb+ files. IIRC, we've built pg_dump with both the "new vc build >>> system" on VS2005 and with the "old win32.mak style build system" with >>> VC++ 6.0, so if we're comfortable enough with that we could just ship >>> binaries built with VC++ for those utilities (even if we don't go to >>> shipping completely MSVC built binaries for 8.3). >>> >>> >>> Thoughts on these options? >>> >>> //Magnus >>> >>> >> Triple bleah. It is not acceptable to say that our only open source tool >> chain can't build fundamentally required functionality. >> >> A little googling on "mingw ftello64" came up with this link, which >> looked somewhat promising: >> >> http://www.nabble.com/RE:-ftello64-returning-wrong-values-p703470.html > > What the heck. So it seems mingw went ahead and implemented their own > ftello64 function *without* using the 64-bit functions as provided by > the standard libraires. Argh. There's also fseeko64(). These are of > course mingw only, so we'll need one codepath for mingw and one for > MSVC, but it does at least seem doable. > > We're still going to have to change from off_t to pgoff_t or similar, > since MSVC will need int64 and mingw will need off64_t.. Right? > > I'll try to take a look at this sometime the next couple of days (out of > time for today) unless beaten to it. >
Actually, there's another option that Hiroshi mentioned off-list, that I forgot. We can implement the Microsoft functions _fseeki64() and _ftelli64() ourselves, based on win32 API functions. There are examples available for this. Not sure which is the cleanest method, too late for more thinking ;-) //Magnus ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
