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