Re: [hatari-devel] windows build failing on cirrus-ci |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] windows build failing on cirrus-ci
- From: Thomas Huth <th.huth@xxxxxxxxx>
- Date: Sat, 27 Apr 2024 04:03:05 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1714190588; bh=VEQwgJujuKEKAzZJsZImKBm5FC+iGFCbxFiGYyjYiNc=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=A5LgAeXZxLyaP4kYuUbPbYUciYCLQ1RX1CgYMnGdg3MbrJjQ1/B4U5MiPETpQN+Qy wE+2JJe5JxnQUxiwYUEwParIjqt9y2fi8yISmCG/hDzfVSIu3FbTtuScBm95MPHeKk 9Q62EUy6VCnmUm41LvhoFsC7EfspaQMRe5whV0atXJS3OuCmenj1ZOui2Ig44bKswy ex8zk9V2XiMnUcVcX6KV0hBFZE9O2SF2Wz5p41NVT6uwLiFmDiQv5fdF/m7sp5cZJM uEIpLW8Prjl5pBRvdzXKTQ6pfFEbv+heAOi+tfdDUY5PNHaK2CwsgotpYHcA4ujIu/ UGOGUkxtKZHsA==
Am Thu, 25 Apr 2024 02:59:29 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> Hi,
>
> On 24.4.2024 17.16, Nicolas Pomarède wrote:
> > since patch "Add autoload support also for TOS debug symbols"
> >
> > the windows build is failing with lots of similar errors about size_t /
> > int conversions :
> >
> > see https://cirrus-ci.com/task/5677615988604928
> >
> > for example
> >
> > src\debug\symbols-common.c(81,1): warning C4267: 'initializing':
> > conversion from 'size_t' to 'int', possible loss of data
> > [C:\Users\ContainerAdministrator\AppData\Local\Temp\cirrus-ci-build\src\debug\Debug.vcxproj]
> >
> > Eero can you have a look to find a common solution for Windows too ?
>
> It's complaining about assigning strlen(), for a debug symbol name, to
> an int.
>
> Although Windows build would be 32-bit, it's quite unlikely that debug
> symbol names within Atari programs, even C++ ones, are so long that they
> would occupy more than 2GB of memory...
>
> And when looking at the other size_t -> int conversion warnings, those
> appear to be even more stupid.
I agree that these warnings are rather unhelpful for the Hatari code. I
tried to disable them now via our vs-fix.h header ... let's see how it
goes...
Thomas