You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Pe...@apache.org on 2026/07/21 10:11:36 UTC
Win64 build issue
Hello Damjan, Hi all,
I am integrating Win64 build on bazel. I am not done yet. But I cam
across an Issue.
sal: fix std::min type ambiguity in osl/w32 profile.cxx on x64 getLine()
computes min(pChr - pFile->m_pReadPtr, MaxLen) where the pointer
difference is ptrdiff_t (64-bit on x64) while MaxLen is int.
When min resolves to std::min -- which it does whenever NOMINMAX is
defined, suppressing the <windows.h> min/max macros -- the two
mismatched argument types make template argument deduction ambiguous:
error C2782: 'const _Ty &std::min(const _Ty &,const _Ty &)' :
template parameter '_Ty' is ambiguous (could be 'int' or '__int64')
On x86 both operands are int (ptrdiff_t == int), so it compiled; only
the x64 pointer-width change exposes it. Disambiguate by casting the
pointer difference to int (the read buffer is small, so the value always
fits). The cast is a no-op on x86 and is correct whether min is the
<windows.h> macro or std::min, so it is safe for every build.
I can Commit in trunk if that makes sense. I did not look deeper into it.
All the best
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Win64 build issue
Posted by Damjan Jovanovic <da...@apache.org>.
On Thu, Jul 23, 2026 at 7:05 AM <Pe...@apache.org> wrote:
> Good Morning Damjan,
>
> Am 22.07.2026 um 19:43 schrieb Damjan Jovanovic:
> > On Tue, Jul 21, 2026 at 12:11 PM<Pe...@apache.org> wrote:
> >
> >> Hello Damjan, Hi all,
> >>
> >>
> > Hi Peter
> >
> >
> >> I am integrating Win64 build on bazel. I am not done yet. But I cam
> >> across an Issue.
> >>
> >> sal: fix std::min type ambiguity in osl/w32 profile.cxx on x64 getLine()
> >> computes min(pChr - pFile->m_pReadPtr, MaxLen) where the pointer
> >> difference is ptrdiff_t (64-bit on x64) while MaxLen is int.
> >>
> >> When min resolves to std::min -- which it does whenever NOMINMAX is
> >> defined, suppressing the <windows.h> min/max macros -- the two
> >> mismatched argument types make template argument deduction ambiguous:
> >> error C2782: 'const _Ty &std::min(const _Ty &,const _Ty &)' :
> >> template parameter '_Ty' is ambiguous (could be 'int' or '__int64')
> >> On x86 both operands are int (ptrdiff_t == int), so it compiled; only
> >> the x64 pointer-width change exposes it. Disambiguate by casting the
> >> pointer difference to int (the read buffer is small, so the value always
> >> fits). The cast is a no-op on x86 and is correct whether min is the
> >> <windows.h> macro or std::min, so it is safe for every build.
> >>
> >> I can Commit in trunk if that makes sense. I did not look deeper into
> it.
> >>
> >>
> > Yes that makes sense, please cast the first argument to int.
>
> Yes that is the fix. I have more fixes in vcl/basic/sfx2/unixODBC. Since
> the bazel-migration is behind trunk, that might be double, sorry i
> forgot to check. I would like to keep the ability to build xp on bazel
> branch for now.
>
> that is why i add gates. bazel will then pull the appropriate dependency
> version depending on build. (currently i add win64, but my idea is to
> change that to WinXP-32, WinXP-64 and Win10-64)
>
> *
> |vcl|:|wincomp.hxx|(|GCLP_|/|GWLP_|+|*LongPtr|),|salframe.cxx|(|PtrToInt|→|static_cast<int>|),|salgdi.cxx|(|sal_uInt32*|),|scrwnd.cxx|(|sal_uIntPtr(1UL)|)
> * |basic/dllmgr.cxx|(|WNT && !_WIN64|)
> * |sfx2/progress.cxx|(|Get10ThSec|decl/def)
> * |unixODBC/sqltypes.h|(|<basetsd.h>|)
>
> should i just commit the changes or would you like to review them?
>
> there is still ongoing work. I guess there will be more changes? or did
> you build a complete win64?
>
>
The windows-amd64 branch is where the most recent Win64 work is.
Regards
Damjan
Re: Win64 build issue
Posted by Pe...@apache.org.
Am 25.07.2026 um 11:10 schrieb Damjan Jovanovic:
>>
>>>> I branched of from trunk into bazel-migration just before Jims Mac
>>>> Silicon patches. I thought you already added win64 patches to trunk.
>>>>
>>>> Turns out that some changes from windows-amd64 branch were not in trunk
>>>> but needed. I totally missed that, so it took me a while to figure that
>>>> one out.
>>>>
>>>> I did not switch to the approach that Jim is using, because i remembered
>>>> that one to late. I did not cherry-pick the commits but copied the code
>>>> snippets i needed.
>>>> There were some more bugs, that needed to be fixed. It seems i have a
>>>> running windows XP 64 bit Version yay!
>>>>
>>>>
>>> Wait, are you saying you fixed the remaining bugs in the AMD64 UNO
>> bridge,
>>> and a Win64 OpenOffice now works?
>> yes, Aoo starts on my bazel environment. I am finalizing everything for
>> bazel-migration push and then port to trunk.
>>
>>
>>
> That's amazing! Excellent work! I was wondering if we'd ever fix it. Thank
> you so much!
Thank you! 😍 I am very happy too. One milestone met. Not in the order i
want to, but that is luxury.
😁
>
> Damjan
All the best
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Win64 build issue
Posted by Damjan Jovanovic <da...@apache.org>.
>
>
> >> I branched of from trunk into bazel-migration just before Jims Mac
> >> Silicon patches. I thought you already added win64 patches to trunk.
> >>
> >> Turns out that some changes from windows-amd64 branch were not in trunk
> >> but needed. I totally missed that, so it took me a while to figure that
> >> one out.
> >>
> >> I did not switch to the approach that Jim is using, because i remembered
> >> that one to late. I did not cherry-pick the commits but copied the code
> >> snippets i needed.
> >> There were some more bugs, that needed to be fixed. It seems i have a
> >> running windows XP 64 bit Version yay!
> >>
> >>
> > Wait, are you saying you fixed the remaining bugs in the AMD64 UNO
> bridge,
> > and a Win64 OpenOffice now works?
>
> yes, Aoo starts on my bazel environment. I am finalizing everything for
> bazel-migration push and then port to trunk.
>
>
>
That's amazing! Excellent work! I was wondering if we'd ever fix it. Thank
you so much!
Damjan
Re: Win64 build issue
Posted by Pe...@apache.org.
Okay bazel-migration has now win-xp-64 and win-xp-32 axis for building.
Sadly I hit the AI session limit, which refreshes in 2h.
The code changes are all single cherry-pick able commits, if you want to
port.
If not i would wait until i get a refresh of my limit in 2h, because i
am not sure if something needs to be adjusted on the build environment
level.
(Not based on my changes as far as i am aware.)
If you could do the cherry-picking and adjusting then i would tackle the
next step. Getting trunk to build with latest sdk on bazel, while
windows xp will fall back to the old VS2009 sdk.
I wonder if i should compile with ms tools or use clang. Maybe have both
axxis?
I would try to build win-10-64, but i would try the adjustments in a way
that bazel still can build xp, win7, win vista, win 10, win 11 - all
supported by the latest sdk.
All the best
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Win64 build issue
Posted by Pe...@apache.org.
Am 25.07.2026 um 10:53 schrieb Damjan Jovanovic:
> On Sat, Jul 25, 2026 at 10:46 AM <Pe...@apache.org> wrote:
>
>> Am 23.07.2026 um 19:19 schrieb Damjan Jovanovic:
>>> On Thu, Jul 23, 2026 at 7:05 AM <Pe...@apache.org> wrote:
>>>
>>>> Good Morning Damjan,
>>>>
>>>> Am 22.07.2026 um 19:43 schrieb Damjan Jovanovic:
>>>>> On Tue, Jul 21, 2026 at 12:11 PM<Pe...@apache.org> wrote:
>>>>>
>>>>>> Hello Damjan, Hi all,
>>>>>>
>>>>>>
>>>>> Hi Peter
>>>>>
>>>>>
>>>>>> I am integrating Win64 build on bazel. I am not done yet. But I cam
>>>>>> across an Issue.
>>>>>>
>>>>>> sal: fix std::min type ambiguity in osl/w32 profile.cxx on x64
>> getLine()
>>>>>> computes min(pChr - pFile->m_pReadPtr, MaxLen) where the pointer
>>>>>> difference is ptrdiff_t (64-bit on x64) while MaxLen is int.
>>>>>>
>>>>>> When min resolves to std::min -- which it does whenever NOMINMAX is
>>>>>> defined, suppressing the <windows.h> min/max macros -- the two
>>>>>> mismatched argument types make template argument deduction ambiguous:
>>>>>> error C2782: 'const _Ty &std::min(const _Ty &,const _Ty &)' :
>>>>>> template parameter '_Ty' is ambiguous (could be 'int' or '__int64')
>>>>>> On x86 both operands are int (ptrdiff_t == int), so it compiled; only
>>>>>> the x64 pointer-width change exposes it. Disambiguate by casting the
>>>>>> pointer difference to int (the read buffer is small, so the value
>> always
>>>>>> fits). The cast is a no-op on x86 and is correct whether min is the
>>>>>> <windows.h> macro or std::min, so it is safe for every build.
>>>>>>
>>>>>> I can Commit in trunk if that makes sense. I did not look deeper into
>>>> it.
>>>>> Yes that makes sense, please cast the first argument to int.
>>>> Yes that is the fix. I have more fixes in vcl/basic/sfx2/unixODBC. Since
>>>> the bazel-migration is behind trunk, that might be double, sorry i
>>>> forgot to check. I would like to keep the ability to build xp on bazel
>>>> branch for now.
>>>>
>>>> that is why i add gates. bazel will then pull the appropriate dependency
>>>> version depending on build. (currently i add win64, but my idea is to
>>>> change that to WinXP-32, WinXP-64 and Win10-64)
>>>>
>>>> *
>>>>
>> |vcl|:|wincomp.hxx|(|GCLP_|/|GWLP_|+|*LongPtr|),|salframe.cxx|(|PtrToInt|→|static_cast<int>|),|salgdi.cxx|(|sal_uInt32*|),|scrwnd.cxx|(|sal_uIntPtr(1UL)|)
>>>> * |basic/dllmgr.cxx|(|WNT && !_WIN64|)
>>>> * |sfx2/progress.cxx|(|Get10ThSec|decl/def)
>>>> * |unixODBC/sqltypes.h|(|<basetsd.h>|)
>>>>
>>>> should i just commit the changes or would you like to review them?
>>> Feel free to commit them, I can always review them in trunk and fix bugs
>>> later :-).
>> Okay i prepare the commits for trunk and i think i go to publish them on
>> bazel-migration too.
>>>
>>>
>>>> there is still ongoing work. I guess there will be more changes? or did
>>>> you build a complete win64?
>>> Build a complete win64 on which branch?
>> I branched of from trunk into bazel-migration just before Jims Mac
>> Silicon patches. I thought you already added win64 patches to trunk.
>>
>> Turns out that some changes from windows-amd64 branch were not in trunk
>> but needed. I totally missed that, so it took me a while to figure that
>> one out.
>>
>> I did not switch to the approach that Jim is using, because i remembered
>> that one to late. I did not cherry-pick the commits but copied the code
>> snippets i needed.
>> There were some more bugs, that needed to be fixed. It seems i have a
>> running windows XP 64 bit Version yay!
>>
>>
> Wait, are you saying you fixed the remaining bugs in the AMD64 UNO bridge,
> and a Win64 OpenOffice now works?
yes, Aoo starts on my bazel environment. I am finalizing everything for
bazel-migration push and then port to trunk.
>
> Regards
> Damjan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Win64 build issue
Posted by Damjan Jovanovic <da...@apache.org>.
On Sat, Jul 25, 2026 at 10:46 AM <Pe...@apache.org> wrote:
>
> Am 23.07.2026 um 19:19 schrieb Damjan Jovanovic:
> > On Thu, Jul 23, 2026 at 7:05 AM <Pe...@apache.org> wrote:
> >
> >> Good Morning Damjan,
> >>
> >> Am 22.07.2026 um 19:43 schrieb Damjan Jovanovic:
> >>> On Tue, Jul 21, 2026 at 12:11 PM<Pe...@apache.org> wrote:
> >>>
> >>>> Hello Damjan, Hi all,
> >>>>
> >>>>
> >>> Hi Peter
> >>>
> >>>
> >>>> I am integrating Win64 build on bazel. I am not done yet. But I cam
> >>>> across an Issue.
> >>>>
> >>>> sal: fix std::min type ambiguity in osl/w32 profile.cxx on x64
> getLine()
> >>>> computes min(pChr - pFile->m_pReadPtr, MaxLen) where the pointer
> >>>> difference is ptrdiff_t (64-bit on x64) while MaxLen is int.
> >>>>
> >>>> When min resolves to std::min -- which it does whenever NOMINMAX is
> >>>> defined, suppressing the <windows.h> min/max macros -- the two
> >>>> mismatched argument types make template argument deduction ambiguous:
> >>>> error C2782: 'const _Ty &std::min(const _Ty &,const _Ty &)' :
> >>>> template parameter '_Ty' is ambiguous (could be 'int' or '__int64')
> >>>> On x86 both operands are int (ptrdiff_t == int), so it compiled; only
> >>>> the x64 pointer-width change exposes it. Disambiguate by casting the
> >>>> pointer difference to int (the read buffer is small, so the value
> always
> >>>> fits). The cast is a no-op on x86 and is correct whether min is the
> >>>> <windows.h> macro or std::min, so it is safe for every build.
> >>>>
> >>>> I can Commit in trunk if that makes sense. I did not look deeper into
> >> it.
> >>>>
> >>> Yes that makes sense, please cast the first argument to int.
> >> Yes that is the fix. I have more fixes in vcl/basic/sfx2/unixODBC. Since
> >> the bazel-migration is behind trunk, that might be double, sorry i
> >> forgot to check. I would like to keep the ability to build xp on bazel
> >> branch for now.
> >>
> >> that is why i add gates. bazel will then pull the appropriate dependency
> >> version depending on build. (currently i add win64, but my idea is to
> >> change that to WinXP-32, WinXP-64 and Win10-64)
> >>
> >> *
> >>
> |vcl|:|wincomp.hxx|(|GCLP_|/|GWLP_|+|*LongPtr|),|salframe.cxx|(|PtrToInt|→|static_cast<int>|),|salgdi.cxx|(|sal_uInt32*|),|scrwnd.cxx|(|sal_uIntPtr(1UL)|)
> >> * |basic/dllmgr.cxx|(|WNT && !_WIN64|)
> >> * |sfx2/progress.cxx|(|Get10ThSec|decl/def)
> >> * |unixODBC/sqltypes.h|(|<basetsd.h>|)
> >>
> >> should i just commit the changes or would you like to review them?
> >
> > Feel free to commit them, I can always review them in trunk and fix bugs
> > later :-).
> Okay i prepare the commits for trunk and i think i go to publish them on
> bazel-migration too.
> >
> >
> >
> >> there is still ongoing work. I guess there will be more changes? or did
> >> you build a complete win64?
> > Build a complete win64 on which branch?
> I branched of from trunk into bazel-migration just before Jims Mac
> Silicon patches. I thought you already added win64 patches to trunk.
>
> Turns out that some changes from windows-amd64 branch were not in trunk
> but needed. I totally missed that, so it took me a while to figure that
> one out.
>
> I did not switch to the approach that Jim is using, because i remembered
> that one to late. I did not cherry-pick the commits but copied the code
> snippets i needed.
> There were some more bugs, that needed to be fixed. It seems i have a
> running windows XP 64 bit Version yay!
>
>
Wait, are you saying you fixed the remaining bugs in the AMD64 UNO bridge,
and a Win64 OpenOffice now works?
Regards
Damjan
Re: Win64 build issue
Posted by Pe...@apache.org.
Am 23.07.2026 um 19:19 schrieb Damjan Jovanovic:
> On Thu, Jul 23, 2026 at 7:05 AM <Pe...@apache.org> wrote:
>
>> Good Morning Damjan,
>>
>> Am 22.07.2026 um 19:43 schrieb Damjan Jovanovic:
>>> On Tue, Jul 21, 2026 at 12:11 PM<Pe...@apache.org> wrote:
>>>
>>>> Hello Damjan, Hi all,
>>>>
>>>>
>>> Hi Peter
>>>
>>>
>>>> I am integrating Win64 build on bazel. I am not done yet. But I cam
>>>> across an Issue.
>>>>
>>>> sal: fix std::min type ambiguity in osl/w32 profile.cxx on x64 getLine()
>>>> computes min(pChr - pFile->m_pReadPtr, MaxLen) where the pointer
>>>> difference is ptrdiff_t (64-bit on x64) while MaxLen is int.
>>>>
>>>> When min resolves to std::min -- which it does whenever NOMINMAX is
>>>> defined, suppressing the <windows.h> min/max macros -- the two
>>>> mismatched argument types make template argument deduction ambiguous:
>>>> error C2782: 'const _Ty &std::min(const _Ty &,const _Ty &)' :
>>>> template parameter '_Ty' is ambiguous (could be 'int' or '__int64')
>>>> On x86 both operands are int (ptrdiff_t == int), so it compiled; only
>>>> the x64 pointer-width change exposes it. Disambiguate by casting the
>>>> pointer difference to int (the read buffer is small, so the value always
>>>> fits). The cast is a no-op on x86 and is correct whether min is the
>>>> <windows.h> macro or std::min, so it is safe for every build.
>>>>
>>>> I can Commit in trunk if that makes sense. I did not look deeper into
>> it.
>>>>
>>> Yes that makes sense, please cast the first argument to int.
>> Yes that is the fix. I have more fixes in vcl/basic/sfx2/unixODBC. Since
>> the bazel-migration is behind trunk, that might be double, sorry i
>> forgot to check. I would like to keep the ability to build xp on bazel
>> branch for now.
>>
>> that is why i add gates. bazel will then pull the appropriate dependency
>> version depending on build. (currently i add win64, but my idea is to
>> change that to WinXP-32, WinXP-64 and Win10-64)
>>
>> *
>> |vcl|:|wincomp.hxx|(|GCLP_|/|GWLP_|+|*LongPtr|),|salframe.cxx|(|PtrToInt|→|static_cast<int>|),|salgdi.cxx|(|sal_uInt32*|),|scrwnd.cxx|(|sal_uIntPtr(1UL)|)
>> * |basic/dllmgr.cxx|(|WNT && !_WIN64|)
>> * |sfx2/progress.cxx|(|Get10ThSec|decl/def)
>> * |unixODBC/sqltypes.h|(|<basetsd.h>|)
>>
>> should i just commit the changes or would you like to review them?
>
> Feel free to commit them, I can always review them in trunk and fix bugs
> later :-).
Okay i prepare the commits for trunk and i think i go to publish them on
bazel-migration too.
>
>
>
>> there is still ongoing work. I guess there will be more changes? or did
>> you build a complete win64?
> Build a complete win64 on which branch?
I branched of from trunk into bazel-migration just before Jims Mac
Silicon patches. I thought you already added win64 patches to trunk.
Turns out that some changes from windows-amd64 branch were not in trunk
but needed. I totally missed that, so it took me a while to figure that
one out.
I did not switch to the approach that Jim is using, because i remembered
that one to late. I did not cherry-pick the commits but copied the code
snippets i needed.
There were some more bugs, that needed to be fixed. It seems i have a
running windows XP 64 bit Version yay!
>
> Regards
> Damjan
All the best
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Win64 build issue
Posted by Damjan Jovanovic <da...@apache.org>.
On Thu, Jul 23, 2026 at 7:05 AM <Pe...@apache.org> wrote:
> Good Morning Damjan,
>
> Am 22.07.2026 um 19:43 schrieb Damjan Jovanovic:
> > On Tue, Jul 21, 2026 at 12:11 PM<Pe...@apache.org> wrote:
> >
> >> Hello Damjan, Hi all,
> >>
> >>
> > Hi Peter
> >
> >
> >> I am integrating Win64 build on bazel. I am not done yet. But I cam
> >> across an Issue.
> >>
> >> sal: fix std::min type ambiguity in osl/w32 profile.cxx on x64 getLine()
> >> computes min(pChr - pFile->m_pReadPtr, MaxLen) where the pointer
> >> difference is ptrdiff_t (64-bit on x64) while MaxLen is int.
> >>
> >> When min resolves to std::min -- which it does whenever NOMINMAX is
> >> defined, suppressing the <windows.h> min/max macros -- the two
> >> mismatched argument types make template argument deduction ambiguous:
> >> error C2782: 'const _Ty &std::min(const _Ty &,const _Ty &)' :
> >> template parameter '_Ty' is ambiguous (could be 'int' or '__int64')
> >> On x86 both operands are int (ptrdiff_t == int), so it compiled; only
> >> the x64 pointer-width change exposes it. Disambiguate by casting the
> >> pointer difference to int (the read buffer is small, so the value always
> >> fits). The cast is a no-op on x86 and is correct whether min is the
> >> <windows.h> macro or std::min, so it is safe for every build.
> >>
> >> I can Commit in trunk if that makes sense. I did not look deeper into
> it.
> >>
> >>
> > Yes that makes sense, please cast the first argument to int.
>
> Yes that is the fix. I have more fixes in vcl/basic/sfx2/unixODBC. Since
> the bazel-migration is behind trunk, that might be double, sorry i
> forgot to check. I would like to keep the ability to build xp on bazel
> branch for now.
>
> that is why i add gates. bazel will then pull the appropriate dependency
> version depending on build. (currently i add win64, but my idea is to
> change that to WinXP-32, WinXP-64 and Win10-64)
>
> *
> |vcl|:|wincomp.hxx|(|GCLP_|/|GWLP_|+|*LongPtr|),|salframe.cxx|(|PtrToInt|→|static_cast<int>|),|salgdi.cxx|(|sal_uInt32*|),|scrwnd.cxx|(|sal_uIntPtr(1UL)|)
> * |basic/dllmgr.cxx|(|WNT && !_WIN64|)
> * |sfx2/progress.cxx|(|Get10ThSec|decl/def)
> * |unixODBC/sqltypes.h|(|<basetsd.h>|)
>
> should i just commit the changes or would you like to review them?
Feel free to commit them, I can always review them in trunk and fix bugs
later :-).
> there is still ongoing work. I guess there will be more changes? or did
> you build a complete win64?
>
>
Build a complete win64 on which branch?
Regards
Damjan
Re: Win64 build issue
Posted by Pe...@apache.org.
Good Morning Damjan,
Am 22.07.2026 um 19:43 schrieb Damjan Jovanovic:
> On Tue, Jul 21, 2026 at 12:11 PM<Pe...@apache.org> wrote:
>
>> Hello Damjan, Hi all,
>>
>>
> Hi Peter
>
>
>> I am integrating Win64 build on bazel. I am not done yet. But I cam
>> across an Issue.
>>
>> sal: fix std::min type ambiguity in osl/w32 profile.cxx on x64 getLine()
>> computes min(pChr - pFile->m_pReadPtr, MaxLen) where the pointer
>> difference is ptrdiff_t (64-bit on x64) while MaxLen is int.
>>
>> When min resolves to std::min -- which it does whenever NOMINMAX is
>> defined, suppressing the <windows.h> min/max macros -- the two
>> mismatched argument types make template argument deduction ambiguous:
>> error C2782: 'const _Ty &std::min(const _Ty &,const _Ty &)' :
>> template parameter '_Ty' is ambiguous (could be 'int' or '__int64')
>> On x86 both operands are int (ptrdiff_t == int), so it compiled; only
>> the x64 pointer-width change exposes it. Disambiguate by casting the
>> pointer difference to int (the read buffer is small, so the value always
>> fits). The cast is a no-op on x86 and is correct whether min is the
>> <windows.h> macro or std::min, so it is safe for every build.
>>
>> I can Commit in trunk if that makes sense. I did not look deeper into it.
>>
>>
> Yes that makes sense, please cast the first argument to int.
Yes that is the fix. I have more fixes in vcl/basic/sfx2/unixODBC. Since
the bazel-migration is behind trunk, that might be double, sorry i
forgot to check. I would like to keep the ability to build xp on bazel
branch for now.
that is why i add gates. bazel will then pull the appropriate dependency
version depending on build. (currently i add win64, but my idea is to
change that to WinXP-32, WinXP-64 and Win10-64)
* |vcl|:|wincomp.hxx|(|GCLP_|/|GWLP_|+|*LongPtr|),|salframe.cxx|(|PtrToInt|→|static_cast<int>|),|salgdi.cxx|(|sal_uInt32*|),|scrwnd.cxx|(|sal_uIntPtr(1UL)|)
* |basic/dllmgr.cxx|(|WNT && !_WIN64|)
* |sfx2/progress.cxx|(|Get10ThSec|decl/def)
* |unixODBC/sqltypes.h|(|<basetsd.h>|)
should i just commit the changes or would you like to review them?
there is still ongoing work. I guess there will be more changes? or did
you build a complete win64?
> All the best
> Damjan
All the best
Peter
Re: Win64 build issue
Posted by Damjan Jovanovic <da...@apache.org>.
On Tue, Jul 21, 2026 at 12:11 PM <Pe...@apache.org> wrote:
> Hello Damjan, Hi all,
>
>
Hi Peter
> I am integrating Win64 build on bazel. I am not done yet. But I cam
> across an Issue.
>
> sal: fix std::min type ambiguity in osl/w32 profile.cxx on x64 getLine()
> computes min(pChr - pFile->m_pReadPtr, MaxLen) where the pointer
> difference is ptrdiff_t (64-bit on x64) while MaxLen is int.
>
> When min resolves to std::min -- which it does whenever NOMINMAX is
> defined, suppressing the <windows.h> min/max macros -- the two
> mismatched argument types make template argument deduction ambiguous:
> error C2782: 'const _Ty &std::min(const _Ty &,const _Ty &)' :
> template parameter '_Ty' is ambiguous (could be 'int' or '__int64')
> On x86 both operands are int (ptrdiff_t == int), so it compiled; only
> the x64 pointer-width change exposes it. Disambiguate by casting the
> pointer difference to int (the read buffer is small, so the value always
> fits). The cast is a no-op on x86 and is correct whether min is the
> <windows.h> macro or std::min, so it is safe for every build.
>
> I can Commit in trunk if that makes sense. I did not look deeper into it.
>
>
Yes that makes sense, please cast the first argument to int.
> All the best
>
> Peter
>
>
>
All the best
Damjan