Libraries are
https://github.com/KiCad/kicad-footprints/releases/tag/5.1.7
https://github.com/KiCad/kicad-symbols/releases/tag/5.1.7
https://github.com/KiCad/kicad-packages3D/releases/tag/5.1.7
https://github.com/KiCad/kicad-templates/releases/tag/5.1.7
Cheers,
CS
Can you run with ASAN on (KICAD_SANITIZE in CMake) and see if you get some
info about why you get a segfault?
On Fri, Sep 25, 2020 at 10:28 AM Franck Jullien
wrote:
> Hi,
>
> I'm working on the intersheets references functionality and I'm
> struggling with a segfault.
> Until now, I didn't try
Hi,
I'm working on the intersheets references functionality and I'm
struggling with a segfault.
Until now, I didn't try to remove iref from sheets. Now, I do this with:
void SCH_EDIT_FRAME::RemoveAllIntersheetsRefs()
{
SCH_SHEET_LIST sheets = Schematic().GetSheets();
SCH_GLOBALLABEL*
Le 25/09/2020 à 16:32, Jon Evans a écrit :
Can you run with ASAN on (KICAD_SANITIZE in CMake) and see if you get
some info about why you get a segfault?
On Fri, Sep 25, 2020 at 10:28 AM Franck Jullien
mailto:franck.jull...@gmail.com>> wrote:
Hi,
I'm working on the intersheets
Thanks for the tip, I didn't know we could run ASAN with Kicad easily.
This is what I get:
==7559==ERROR: AddressSanitizer: heap-use-after-free on address
0x612403c4 at pc 0x7f1ec5130bb9 bp 0x7ffe8351d540 sp
0x7ffe8351d530
READ of size 4 at 0x612403c4 thread T0
#0 0x7f1ec5130bb8 in
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
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
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
Thank you Seth, it works now.
@Jean-Pierre : I'll do what you suggested and iterate over screens
instead of sheets.
Franck.
Le ven. 25 sept. 2020 à 19:10, Seth Hillbrand a écrit :
>
> Hi Franck-
>
> You cannot delete items from the rtree while iterating over it, the
> references are
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:
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
I just pushed the 5.1.7 tagged commit to GitLab. How are we doing on
tagging the libraries, docs, and translations. I would like to make the
release announcement either 9/30 or 10/1 if possible. Thank you to all
of our developers who made this possible.
Cheers,
Wayne
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
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
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
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
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
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
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
>
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
20 matches
Mail list logo
