Yes, sorry I realised the long conversation that happened between me
starting the MSYS build and sending the email reply to you. Definitely MSVC
is much faster compile time (20 mins vs 2 hours on my computer). It only
needs a CMakeSettings.json file in the root folder of the project and it
works li
They were all clean config and build.
On 9/25/20 5:46 PM, Roberto Fernández Bautista wrote:
> Hi Wayne
>
> I just did a clean build of master in MingW64 / msys2 and did not see
> the error you report (using gcc 10.1)
>
> Maybe there is something strange in your configuration / might just need
>
Hi Wayne
I just did a clean build of master in MingW64 / msys2 and did not see the
error you report (using gcc 10.1)
Maybe there is something strange in your configuration / might just need to
do a clean before re-building?
Roberto.
On Fri, 25 Sep 2020 at 18:11, Wayne Stambaugh wrote:
> Is an
Ni, they are only cached via the archive artifacts of jenkins, which I
can't reach right now.
fre. 25. sep. 2020 22.39 skrev Wayne Stambaugh :
> Is there a repo with with the build configuration so I can see what
> msys2/mingw64 packages are being used in our builds?
>
> On 9/25/20 4:09 PM, Nick
Is there a repo with with the build configuration so I can see what
msys2/mingw64 packages are being used in our builds?
On 9/25/20 4:09 PM, Nick Østergaard wrote:
> I cant reach the build server right now, so I don't know the status, but
> it is not autoupdated. Mainly updated once in a while aft
I cant reach the build server right now, so I don't know the status, but it
is not autoupdated. Mainly updated once in a while after a release has been
made with "known good env".
fre. 25. sep. 2020 22.02 skrev Wayne Stambaugh :
> I take it we are not getting any nightly build errors for msys2/mi
It's on my short list. Unfortunately, my short list keeps getting longer.
On 9/25/20 3:13 PM, Jon Evans wrote:
> MSVC works great, I really recommend giving it a try. Much faster
> compile time than msys.
>
> Seems like Mark will have a solution for wxPython very soon too :)
>
> On Fri, Sep 25
I take it we are not getting any nightly build errors for msys2/mingw54
builds. Do we always use the latest msys2/mingw64 packages for nightly
builds or are they pinned to a specific version that we know works? If
it's the latter, where can I find the package list. Maybe that will
give me a bett
I actually got that MSYS2 error awhile backas for why, I don't know, I
haven't been arsed to rebuild the msys2 install yet again.
I'm waiting on vcpkg to merge opencascade which was blocked on 32-bit
builds being broken, the MSVC team responded with a workaround to the
compiler bug so now its
MSVC works great, I really recommend giving it a try. Much faster compile
time than msys.
Seems like Mark will have a solution for wxPython very soon too :)
On Fri, Sep 25, 2020 at 3:10 PM Wayne Stambaugh
wrote:
> On 9/25/2020 3:04 PM, jp charras wrote:
> >
> > Le 25/09/2020 à 19:11, Wayne Sta
On 9/25/2020 3:04 PM, jp charras wrote:
>
> Le 25/09/2020 à 19:11, Wayne Stambaugh a écrit :
>> Is anyone else seeing the following error when building with
>> MinGW64/msys2?
>>
>> ../common/libcommon.a(libcontext.cpp.obj):libcontext.cpp:(.text+0x19e):
>> relocation truncated to fit: R_X86_64_PC32
Le 25/09/2020 à 19:11, Wayne Stambaugh a écrit :
Is anyone else seeing the following error when building with MinGW64/msys2?
../common/libcommon.a(libcontext.cpp.obj):libcontext.cpp:(.text+0x19e):
relocation truncated to fit: R_X86_64_PC32 against `*ABS*'
I did some digging around and it looks
Is anyone else seeing the following error when building with MinGW64/msys2?
../common/libcommon.a(libcontext.cpp.obj):libcontext.cpp:(.text+0x19e):
relocation truncated to fit: R_X86_64_PC32 against `*ABS*'
I did some digging around and it looks like it's a bug in the context
assembly code but I'
13 matches
Mail list logo