Magnus Hagander wrote:
>>> I suspect we might need to create a pg_off_t type or some such gadget.
>>>
>>> Bleah.
>>>
>>> But it does need to be fixed.
>>>
>> Bummer. That might be what's needed, but I'm going to at least try to
>> find some neater way first. I wonder why it didn't happen on MSVC...
>>
>
> 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
cheers
andrew