>> 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.
//Magnus