On Sat, Jul 25, 2026 at 10:46 AM <[email protected]> wrote: > > Am 23.07.2026 um 19:19 schrieb Damjan Jovanovic: > > On Thu, Jul 23, 2026 at 7:05 AM <[email protected]> wrote: > > > >> Good Morning Damjan, > >> > >> Am 22.07.2026 um 19:43 schrieb Damjan Jovanovic: > >>> On Tue, Jul 21, 2026 at 12:11 PM<[email protected]> 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
