Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Jon Evans]

If it is the commit I made that Ian points out, I won't be able to debug it
very effectively.  I don't have a msys2 build environment, and it seems to
work on all the platforms I do have.

On Wed, Jul 22, 2020 at 6:38 PM Wayne Stambaugh 
wrote:

> No problem.  I'll file a issue report as soon as I determine the guilty
> commit.
>
> On 7/22/2020 6:34 PM, Ian McInerney wrote:
> > It was committed on July 3rd. I am not sure which commit is 100 behind
> > the current head though, and I really don't want to kill my build
> > directory by switching that far back to find out.
> >
> > -Ian
> >
> > On Wed, Jul 22, 2020 at 11:27 PM Wayne Stambaugh  > > wrote:
> >
> > I'm running `git bisect` now from HEAD~100.  Is it further back that
> > that?  Given that mingw debug builds are painfully slow, it's going
> to
> > take a while.
> >
> > On 7/22/2020 6:17 PM, Ian McInerney wrote:
> > > Try going right before c0aa6965de7b83ca78dd5c4d700b50a2a03a34e4
> first.
> > > The errors that Brian showed at the beginning of the thread mention
> > > NETCLASS* and shared_ptr stuff, and it looks like the last commit
> that
> > > touched those Swig parts was from Jon on June 30th which moved
> > that from
> > > pcbnew to the common Swig directory. I am not sure how that could
> have
> > > broken things, but I think it would be a good commit to start with
> and
> > > see if it is the issue.
> > >
> > > -Ian
> > >
> > > On Wed, Jul 22, 2020 at 11:10 PM Brian Piccioni
> > > mailto:br...@documenteddesigns.com>
> >  > >> wrote:
> > >
> > > Perhaps what I can try and do is a binary search for the last
> > "working"
> > > master.
> > >
> > > I think that is within my abilities.
> > >
> > > On 2020-07-22 6:00 p.m., Jon Evans wrote:
> > > > If you know a version that builds (you said late June
> > worked) you can
> > > > do a git bisect against a commit from back then and
> > eventually this
> > > > will tell you which commit changed the behavior
> > > >
> > > > On Wed, Jul 22, 2020 at 5:58 PM Brian Piccioni
> > > >  > 
> >  > >>
> > > wrote:
> > > >> You can't imagine how happy it makes me feel to know it
> > isn't some
> > > >> stupid little thing I did.
> > > >>
> > > >> I don't know how I can help though. I can try building a
> > release
> > > version
> > > >> to confirm.
> > > >>
> > > >> On 2020-07-22 5:54 p.m., Wayne Stambaugh wrote:
> > > >>> I've been playing around with this and there is definetly
> > something
> > > >>> amiss.  I don't get the build errors on release builds but
> > I do
> > > see them
> > > >>> with debug builds (CMAKE_BUILD_TYPE=Debug).  Downgrading
> > swig from
> > > >>> 4.0.2-1 to 4.0.1-3 didn't help.  Interestingly the 5.1
> > branch builds
> > > >>> just fine so I suspect a recent change in the one of the
> CMake
> > > config
> > > >>> files is to blame.  I don't remember seeing any swig
> changes
> > > recently.
> > > >>>
> > > >>> On 7/22/2020 9:30 AM, Brian Piccioni wrote:
> > >  Using this script
> > > 
> > >  cmake -DCMAKE_BUILD_TYPE=Debug -G "MSYS Makefiles"
> > >  -DCMAKE_PREFIX_PATH=C:/msys64/mingw64
> > >  -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64
> > >  -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 -DMSYS=TRUE
> ../kicad
> > > 
> > >  I get the same results
> > > 
> > >  [ 98%] Built target qa_eeschema
> > > 
> > >
> >
>   
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > > 
> > >
> >
>   
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
> > >  undefined reference to `.refptr.PyObject_GenericGetAttr'
> > > 
> > >
> >
>   
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > > 
> > CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> > > function
> > > 
> > `std::invalid_argument::invalid_argument(std::invalid_argument
> > > const&)':
> > >  C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174:
> undefined
> > > reference
> > >  to `.refptr._ZTVSt16invalid_argument'
> > > 
> > >
> >
>   
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > 

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Wayne Stambaugh]

No problem.  I'll file a issue report as soon as I determine the guilty
commit.

On 7/22/2020 6:34 PM, Ian McInerney wrote:
> It was committed on July 3rd. I am not sure which commit is 100 behind
> the current head though, and I really don't want to kill my build
> directory by switching that far back to find out.
> 
> -Ian
> 
> On Wed, Jul 22, 2020 at 11:27 PM Wayne Stambaugh  > wrote:
> 
> I'm running `git bisect` now from HEAD~100.  Is it further back that
> that?  Given that mingw debug builds are painfully slow, it's going to
> take a while.
> 
> On 7/22/2020 6:17 PM, Ian McInerney wrote:
> > Try going right before c0aa6965de7b83ca78dd5c4d700b50a2a03a34e4 first.
> > The errors that Brian showed at the beginning of the thread mention
> > NETCLASS* and shared_ptr stuff, and it looks like the last commit that
> > touched those Swig parts was from Jon on June 30th which moved
> that from
> > pcbnew to the common Swig directory. I am not sure how that could have
> > broken things, but I think it would be a good commit to start with and
> > see if it is the issue.
> >
> > -Ian
> >
> > On Wed, Jul 22, 2020 at 11:10 PM Brian Piccioni
> > mailto:br...@documenteddesigns.com>
>  >> wrote:
> >
> >     Perhaps what I can try and do is a binary search for the last
> "working"
> >     master.
> >
> >     I think that is within my abilities.
> >
> >     On 2020-07-22 6:00 p.m., Jon Evans wrote:
> >     > If you know a version that builds (you said late June
> worked) you can
> >     > do a git bisect against a commit from back then and
> eventually this
> >     > will tell you which commit changed the behavior
> >     >
> >     > On Wed, Jul 22, 2020 at 5:58 PM Brian Piccioni
> >     >  
>  >>
> >     wrote:
> >     >> You can't imagine how happy it makes me feel to know it
> isn't some
> >     >> stupid little thing I did.
> >     >>
> >     >> I don't know how I can help though. I can try building a
> release
> >     version
> >     >> to confirm.
> >     >>
> >     >> On 2020-07-22 5:54 p.m., Wayne Stambaugh wrote:
> >     >>> I've been playing around with this and there is definetly
> something
> >     >>> amiss.  I don't get the build errors on release builds but
> I do
> >     see them
> >     >>> with debug builds (CMAKE_BUILD_TYPE=Debug).  Downgrading
> swig from
> >     >>> 4.0.2-1 to 4.0.1-3 didn't help.  Interestingly the 5.1
> branch builds
> >     >>> just fine so I suspect a recent change in the one of the CMake
> >     config
> >     >>> files is to blame.  I don't remember seeing any swig changes
> >     recently.
> >     >>>
> >     >>> On 7/22/2020 9:30 AM, Brian Piccioni wrote:
> >      Using this script
> >     
> >      cmake -DCMAKE_BUILD_TYPE=Debug -G "MSYS Makefiles"
> >      -DCMAKE_PREFIX_PATH=C:/msys64/mingw64
> >      -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64
> >      -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 -DMSYS=TRUE ../kicad
> >     
> >      I get the same results
> >     
> >      [ 98%] Built target qa_eeschema
> >     
> >   
>  
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >     
> >   
>  
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
> >      undefined reference to `.refptr.PyObject_GenericGetAttr'
> >     
> >   
>  
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >     
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> >     function
> >     
> `std::invalid_argument::invalid_argument(std::invalid_argument
> >     const&)':
> >      C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined
> >     reference
> >      to `.refptr._ZTVSt16invalid_argument'
> >     
> >   
>  
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >     
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> >     function
> >      `std::_Sp_counted_deleter >      std::allocator,
> >      (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info
> >     const&)':
> >     
> C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
> >      undefined reference to `typeinfo for SWIG_null_deleter'
> >     
> >  

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Ian McInerney]

It was committed on July 3rd. I am not sure which commit is 100 behind the
current head though, and I really don't want to kill my build directory by
switching that far back to find out.

-Ian

On Wed, Jul 22, 2020 at 11:27 PM Wayne Stambaugh 
wrote:

> I'm running `git bisect` now from HEAD~100.  Is it further back that
> that?  Given that mingw debug builds are painfully slow, it's going to
> take a while.
>
> On 7/22/2020 6:17 PM, Ian McInerney wrote:
> > Try going right before c0aa6965de7b83ca78dd5c4d700b50a2a03a34e4 first.
> > The errors that Brian showed at the beginning of the thread mention
> > NETCLASS* and shared_ptr stuff, and it looks like the last commit that
> > touched those Swig parts was from Jon on June 30th which moved that from
> > pcbnew to the common Swig directory. I am not sure how that could have
> > broken things, but I think it would be a good commit to start with and
> > see if it is the issue.
> >
> > -Ian
> >
> > On Wed, Jul 22, 2020 at 11:10 PM Brian Piccioni
> > mailto:br...@documenteddesigns.com>>
> wrote:
> >
> > Perhaps what I can try and do is a binary search for the last
> "working"
> > master.
> >
> > I think that is within my abilities.
> >
> > On 2020-07-22 6:00 p.m., Jon Evans wrote:
> > > If you know a version that builds (you said late June worked) you
> can
> > > do a git bisect against a commit from back then and eventually this
> > > will tell you which commit changed the behavior
> > >
> > > On Wed, Jul 22, 2020 at 5:58 PM Brian Piccioni
> > > mailto:br...@documenteddesigns.com>>
> > wrote:
> > >> You can't imagine how happy it makes me feel to know it isn't some
> > >> stupid little thing I did.
> > >>
> > >> I don't know how I can help though. I can try building a release
> > version
> > >> to confirm.
> > >>
> > >> On 2020-07-22 5:54 p.m., Wayne Stambaugh wrote:
> > >>> I've been playing around with this and there is definetly
> something
> > >>> amiss.  I don't get the build errors on release builds but I do
> > see them
> > >>> with debug builds (CMAKE_BUILD_TYPE=Debug).  Downgrading swig
> from
> > >>> 4.0.2-1 to 4.0.1-3 didn't help.  Interestingly the 5.1 branch
> builds
> > >>> just fine so I suspect a recent change in the one of the CMake
> > config
> > >>> files is to blame.  I don't remember seeing any swig changes
> > recently.
> > >>>
> > >>> On 7/22/2020 9:30 AM, Brian Piccioni wrote:
> >  Using this script
> > 
> >  cmake -DCMAKE_BUILD_TYPE=Debug -G "MSYS Makefiles"
> >  -DCMAKE_PREFIX_PATH=C:/msys64/mingw64
> >  -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64
> >  -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 -DMSYS=TRUE ../kicad
> > 
> >  I get the same results
> > 
> >  [ 98%] Built target qa_eeschema
> > 
> >
>  
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > 
> >
>  
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
> >  undefined reference to `.refptr.PyObject_GenericGetAttr'
> > 
> >
>  
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >  CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> > function
> >  `std::invalid_argument::invalid_argument(std::invalid_argument
> > const&)':
> >  C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined
> > reference
> >  to `.refptr._ZTVSt16invalid_argument'
> > 
> >
>  
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >  CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> > function
> >  `std::_Sp_counted_deleter >  std::allocator,
> >  (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info
> > const&)':
> >  C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
> >  undefined reference to `typeinfo for SWIG_null_deleter'
> > 
> >
>  
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >  CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> > function
> >  `swig::traits_from::from(KIID const&)':
> > 
> >
>  
> C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929:
> >  undefined reference to
> > `swig::traits_from_ptr::from(KIID*, int)'
> > 
> >
>  
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > 
> >
>  
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8):
> >  undefined reference to `typeinfo name for SWIG_null_deleter'
> > 

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Wayne Stambaugh]

I'm running `git bisect` now from HEAD~100.  Is it further back that
that?  Given that mingw debug builds are painfully slow, it's going to
take a while.

On 7/22/2020 6:17 PM, Ian McInerney wrote:
> Try going right before c0aa6965de7b83ca78dd5c4d700b50a2a03a34e4 first.
> The errors that Brian showed at the beginning of the thread mention
> NETCLASS* and shared_ptr stuff, and it looks like the last commit that
> touched those Swig parts was from Jon on June 30th which moved that from
> pcbnew to the common Swig directory. I am not sure how that could have
> broken things, but I think it would be a good commit to start with and
> see if it is the issue.
> 
> -Ian
> 
> On Wed, Jul 22, 2020 at 11:10 PM Brian Piccioni
> mailto:br...@documenteddesigns.com>> wrote:
> 
> Perhaps what I can try and do is a binary search for the last "working"
> master.
> 
> I think that is within my abilities.
> 
> On 2020-07-22 6:00 p.m., Jon Evans wrote:
> > If you know a version that builds (you said late June worked) you can
> > do a git bisect against a commit from back then and eventually this
> > will tell you which commit changed the behavior
> >
> > On Wed, Jul 22, 2020 at 5:58 PM Brian Piccioni
> > mailto:br...@documenteddesigns.com>>
> wrote:
> >> You can't imagine how happy it makes me feel to know it isn't some
> >> stupid little thing I did.
> >>
> >> I don't know how I can help though. I can try building a release
> version
> >> to confirm.
> >>
> >> On 2020-07-22 5:54 p.m., Wayne Stambaugh wrote:
> >>> I've been playing around with this and there is definetly something
> >>> amiss.  I don't get the build errors on release builds but I do
> see them
> >>> with debug builds (CMAKE_BUILD_TYPE=Debug).  Downgrading swig from
> >>> 4.0.2-1 to 4.0.1-3 didn't help.  Interestingly the 5.1 branch builds
> >>> just fine so I suspect a recent change in the one of the CMake
> config
> >>> files is to blame.  I don't remember seeing any swig changes
> recently.
> >>>
> >>> On 7/22/2020 9:30 AM, Brian Piccioni wrote:
>  Using this script
> 
>  cmake -DCMAKE_BUILD_TYPE=Debug -G "MSYS Makefiles"
>  -DCMAKE_PREFIX_PATH=C:/msys64/mingw64
>  -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64
>  -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 -DMSYS=TRUE ../kicad
> 
>  I get the same results
> 
>  [ 98%] Built target qa_eeschema
> 
> 
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> 
> 
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
>  undefined reference to `.refptr.PyObject_GenericGetAttr'
> 
> 
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>  CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> function
>  `std::invalid_argument::invalid_argument(std::invalid_argument
> const&)':
>  C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined
> reference
>  to `.refptr._ZTVSt16invalid_argument'
> 
> 
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>  CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> function
>  `std::_Sp_counted_deleter  std::allocator,
>  (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info
> const&)':
>  C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
>  undefined reference to `typeinfo for SWIG_null_deleter'
> 
> 
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>  CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> function
>  `swig::traits_from::from(KIID const&)':
> 
> 
> C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929:
>  undefined reference to
> `swig::traits_from_ptr::from(KIID*, int)'
> 
> 
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> 
> 
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8):
>  undefined reference to `typeinfo name for SWIG_null_deleter'
>  collect2.exe: error: ld returned 1 exit status
>  make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:634:
>  pcbnew/_pcbnew.kiface] Error 1
>  make[1]: *** [CMakeFiles/Makefile2:3284:
>  pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2
>  make: *** [Makefile:161: all] Error 2
> 
>  bjpic@LAPTOP-70Q5CT1Q MINGW64 ~/FixedFormatting/clean/debug
> 
>  On 

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Ian McInerney]

Try going right before c0aa6965de7b83ca78dd5c4d700b50a2a03a34e4 first. The
errors that Brian showed at the beginning of the thread mention NETCLASS*
and shared_ptr stuff, and it looks like the last commit that touched those
Swig parts was from Jon on June 30th which moved that from pcbnew to the
common Swig directory. I am not sure how that could have broken things, but
I think it would be a good commit to start with and see if it is the issue.

-Ian

On Wed, Jul 22, 2020 at 11:10 PM Brian Piccioni 
wrote:

> Perhaps what I can try and do is a binary search for the last "working"
> master.
>
> I think that is within my abilities.
>
> On 2020-07-22 6:00 p.m., Jon Evans wrote:
> > If you know a version that builds (you said late June worked) you can
> > do a git bisect against a commit from back then and eventually this
> > will tell you which commit changed the behavior
> >
> > On Wed, Jul 22, 2020 at 5:58 PM Brian Piccioni
> >  wrote:
> >> You can't imagine how happy it makes me feel to know it isn't some
> >> stupid little thing I did.
> >>
> >> I don't know how I can help though. I can try building a release version
> >> to confirm.
> >>
> >> On 2020-07-22 5:54 p.m., Wayne Stambaugh wrote:
> >>> I've been playing around with this and there is definetly something
> >>> amiss.  I don't get the build errors on release builds but I do see
> them
> >>> with debug builds (CMAKE_BUILD_TYPE=Debug).  Downgrading swig from
> >>> 4.0.2-1 to 4.0.1-3 didn't help.  Interestingly the 5.1 branch builds
> >>> just fine so I suspect a recent change in the one of the CMake config
> >>> files is to blame.  I don't remember seeing any swig changes recently.
> >>>
> >>> On 7/22/2020 9:30 AM, Brian Piccioni wrote:
>  Using this script
> 
>  cmake -DCMAKE_BUILD_TYPE=Debug -G "MSYS Makefiles"
>  -DCMAKE_PREFIX_PATH=C:/msys64/mingw64
>  -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64
>  -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 -DMSYS=TRUE ../kicad
> 
>  I get the same results
> 
>  [ 98%] Built target qa_eeschema
> 
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> 
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
>  undefined reference to `.refptr.PyObject_GenericGetAttr'
> 
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>  CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> function
>  `std::invalid_argument::invalid_argument(std::invalid_argument
> const&)':
>  C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined
> reference
>  to `.refptr._ZTVSt16invalid_argument'
> 
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>  CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> function
>  `std::_Sp_counted_deleter  std::allocator,
>  (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
>  C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
>  undefined reference to `typeinfo for SWIG_null_deleter'
> 
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>  CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> function
>  `swig::traits_from::from(KIID const&)':
> 
> C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929:
>  undefined reference to `swig::traits_from_ptr::from(KIID*, int)'
> 
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> 
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8):
>  undefined reference to `typeinfo name for SWIG_null_deleter'
>  collect2.exe: error: ld returned 1 exit status
>  make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:634:
>  pcbnew/_pcbnew.kiface] Error 1
>  make[1]: *** [CMakeFiles/Makefile2:3284:
>  pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2
>  make: *** [Makefile:161: all] Error 2
> 
>  bjpic@LAPTOP-70Q5CT1Q MINGW64 ~/FixedFormatting/clean/debug
> 
>  On 2020-07-22 2:39 a.m., Nick Østergaard wrote:
> > Did you try to use the normal makefile generator rather than the
> > eclipse one?
> >
> > ons. 22. jul. 2020 01.37 skrev Brian Piccioni
> > mailto:br...@documenteddesigns.com>>:
> >
> >   FWIW, I re-cloned Kicad master into an empty directory,
> created a
> >   new build directory, ran the standard build script
> >
> >   cmake -DCMAKE_BUILD_TYPE=Debug \
> >   -G "Eclipse CDT4 - Unix Makefiles" \
> >   -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
> >   -DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
> >   -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
> >   

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Brian Piccioni]

Perhaps what I can try and do is a binary search for the last "working" 
master.


I think that is within my abilities.

On 2020-07-22 6:00 p.m., Jon Evans wrote:

If you know a version that builds (you said late June worked) you can
do a git bisect against a commit from back then and eventually this
will tell you which commit changed the behavior

On Wed, Jul 22, 2020 at 5:58 PM Brian Piccioni
 wrote:

You can't imagine how happy it makes me feel to know it isn't some
stupid little thing I did.

I don't know how I can help though. I can try building a release version
to confirm.

On 2020-07-22 5:54 p.m., Wayne Stambaugh wrote:

I've been playing around with this and there is definetly something
amiss.  I don't get the build errors on release builds but I do see them
with debug builds (CMAKE_BUILD_TYPE=Debug).  Downgrading swig from
4.0.2-1 to 4.0.1-3 didn't help.  Interestingly the 5.1 branch builds
just fine so I suspect a recent change in the one of the CMake config
files is to blame.  I don't remember seeing any swig changes recently.

On 7/22/2020 9:30 AM, Brian Piccioni wrote:

Using this script

cmake -DCMAKE_BUILD_TYPE=Debug -G "MSYS Makefiles"
-DCMAKE_PREFIX_PATH=C:/msys64/mingw64
-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64
-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 -DMSYS=TRUE ../kicad

I get the same results

[ 98%] Built target qa_eeschema
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
undefined reference to `.refptr.PyObject_GenericGetAttr'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
`std::invalid_argument::invalid_argument(std::invalid_argument const&)':
C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined reference
to `.refptr._ZTVSt16invalid_argument'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
`std::_Sp_counted_deleter,
(__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
undefined reference to `typeinfo for SWIG_null_deleter'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
`swig::traits_from::from(KIID const&)':
C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929:
undefined reference to `swig::traits_from_ptr::from(KIID*, int)'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8):
undefined reference to `typeinfo name for SWIG_null_deleter'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:634:
pcbnew/_pcbnew.kiface] Error 1
make[1]: *** [CMakeFiles/Makefile2:3284:
pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2
make: *** [Makefile:161: all] Error 2

bjpic@LAPTOP-70Q5CT1Q MINGW64 ~/FixedFormatting/clean/debug

On 2020-07-22 2:39 a.m., Nick Østergaard wrote:

Did you try to use the normal makefile generator rather than the
eclipse one?

ons. 22. jul. 2020 01.37 skrev Brian Piccioni
mailto:br...@documenteddesigns.com>>:

  FWIW, I re-cloned Kicad master into an empty directory, created a
  new build directory, ran the standard build script

  cmake -DCMAKE_BUILD_TYPE=Debug \
  -G "Eclipse CDT4 - Unix Makefiles" \
  -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
  -DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
  -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
  -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
  -DMSYS=TRUE \
  ../kicad

  and got the same errors

   Built target qa_eeschema
  
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
  
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
  undefined reference to `.refptr.PyObject_GenericGetAttr'
  
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
  CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
  function
  `std::invalid_argument::invalid_argument(std::invalid_argument
  const&)':
  C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined
  reference to `.refptr._ZTVSt16invalid_argument'
  
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
  CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
  function `std::_Sp_counted_deleter,
  

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Jon Evans]

If you know a version that builds (you said late June worked) you can
do a git bisect against a commit from back then and eventually this
will tell you which commit changed the behavior

On Wed, Jul 22, 2020 at 5:58 PM Brian Piccioni
 wrote:
>
> You can't imagine how happy it makes me feel to know it isn't some
> stupid little thing I did.
>
> I don't know how I can help though. I can try building a release version
> to confirm.
>
> On 2020-07-22 5:54 p.m., Wayne Stambaugh wrote:
> > I've been playing around with this and there is definetly something
> > amiss.  I don't get the build errors on release builds but I do see them
> > with debug builds (CMAKE_BUILD_TYPE=Debug).  Downgrading swig from
> > 4.0.2-1 to 4.0.1-3 didn't help.  Interestingly the 5.1 branch builds
> > just fine so I suspect a recent change in the one of the CMake config
> > files is to blame.  I don't remember seeing any swig changes recently.
> >
> > On 7/22/2020 9:30 AM, Brian Piccioni wrote:
> >> Using this script
> >>
> >> cmake -DCMAKE_BUILD_TYPE=Debug -G "MSYS Makefiles"
> >> -DCMAKE_PREFIX_PATH=C:/msys64/mingw64
> >> -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64
> >> -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 -DMSYS=TRUE ../kicad
> >>
> >> I get the same results
> >>
> >> [ 98%] Built target qa_eeschema
> >> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
> >> undefined reference to `.refptr.PyObject_GenericGetAttr'
> >> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
> >> `std::invalid_argument::invalid_argument(std::invalid_argument const&)':
> >> C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined reference
> >> to `.refptr._ZTVSt16invalid_argument'
> >> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
> >> `std::_Sp_counted_deleter >> std::allocator,
> >> (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
> >> C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
> >> undefined reference to `typeinfo for SWIG_null_deleter'
> >> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
> >> `swig::traits_from::from(KIID const&)':
> >> C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929:
> >> undefined reference to `swig::traits_from_ptr::from(KIID*, int)'
> >> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8):
> >> undefined reference to `typeinfo name for SWIG_null_deleter'
> >> collect2.exe: error: ld returned 1 exit status
> >> make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:634:
> >> pcbnew/_pcbnew.kiface] Error 1
> >> make[1]: *** [CMakeFiles/Makefile2:3284:
> >> pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2
> >> make: *** [Makefile:161: all] Error 2
> >>
> >> bjpic@LAPTOP-70Q5CT1Q MINGW64 ~/FixedFormatting/clean/debug
> >>
> >> On 2020-07-22 2:39 a.m., Nick Østergaard wrote:
> >>> Did you try to use the normal makefile generator rather than the
> >>> eclipse one?
> >>>
> >>> ons. 22. jul. 2020 01.37 skrev Brian Piccioni
> >>> mailto:br...@documenteddesigns.com>>:
> >>>
> >>>  FWIW, I re-cloned Kicad master into an empty directory, created a
> >>>  new build directory, ran the standard build script
> >>>
> >>>  cmake -DCMAKE_BUILD_TYPE=Debug \
> >>>  -G "Eclipse CDT4 - Unix Makefiles" \
> >>>  -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
> >>>  -DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
> >>>  -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
> >>>  -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
> >>>  -DMSYS=TRUE \
> >>>  ../kicad
> >>>
> >>>  and got the same errors
> >>>
> >>>   Built target qa_eeschema
> >>>  
> >>> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >>>  
> >>> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
> >>>  undefined reference to `.refptr.PyObject_GenericGetAttr'
> >>>  
> >>> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >>>  CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> >>>  function
> >>>  `std::invalid_argument::invalid_argument(std::invalid_argument
> >>>  const&)':
> >>>  C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined
> >>>  reference to 

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Brian Piccioni]

You can't imagine how happy it makes me feel to know it isn't some 
stupid little thing I did.


I don't know how I can help though. I can try building a release version 
to confirm.


On 2020-07-22 5:54 p.m., Wayne Stambaugh wrote:

I've been playing around with this and there is definetly something
amiss.  I don't get the build errors on release builds but I do see them
with debug builds (CMAKE_BUILD_TYPE=Debug).  Downgrading swig from
4.0.2-1 to 4.0.1-3 didn't help.  Interestingly the 5.1 branch builds
just fine so I suspect a recent change in the one of the CMake config
files is to blame.  I don't remember seeing any swig changes recently.

On 7/22/2020 9:30 AM, Brian Piccioni wrote:

Using this script

cmake -DCMAKE_BUILD_TYPE=Debug -G "MSYS Makefiles"
-DCMAKE_PREFIX_PATH=C:/msys64/mingw64
-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64
-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 -DMSYS=TRUE ../kicad

I get the same results

[ 98%] Built target qa_eeschema
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
undefined reference to `.refptr.PyObject_GenericGetAttr'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
`std::invalid_argument::invalid_argument(std::invalid_argument const&)':
C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined reference
to `.refptr._ZTVSt16invalid_argument'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
`std::_Sp_counted_deleter,
(__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
undefined reference to `typeinfo for SWIG_null_deleter'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
`swig::traits_from::from(KIID const&)':
C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929:
undefined reference to `swig::traits_from_ptr::from(KIID*, int)'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8):
undefined reference to `typeinfo name for SWIG_null_deleter'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:634:
pcbnew/_pcbnew.kiface] Error 1
make[1]: *** [CMakeFiles/Makefile2:3284:
pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2
make: *** [Makefile:161: all] Error 2

bjpic@LAPTOP-70Q5CT1Q MINGW64 ~/FixedFormatting/clean/debug

On 2020-07-22 2:39 a.m., Nick Østergaard wrote:

Did you try to use the normal makefile generator rather than the
eclipse one?

ons. 22. jul. 2020 01.37 skrev Brian Piccioni
mailto:br...@documenteddesigns.com>>:

 FWIW, I re-cloned Kicad master into an empty directory, created a
 new build directory, ran the standard build script

 cmake -DCMAKE_BUILD_TYPE=Debug \
 -G "Eclipse CDT4 - Unix Makefiles" \
 -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
 -DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
 -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
 -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
 -DMSYS=TRUE \
 ../kicad

 and got the same errors

  Built target qa_eeschema
 
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
 undefined reference to `.refptr.PyObject_GenericGetAttr'
 
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
 function
 `std::invalid_argument::invalid_argument(std::invalid_argument
 const&)':
 C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined
 reference to `.refptr._ZTVSt16invalid_argument'
 
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
 function `std::_Sp_counted_deleter,
 (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
 C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
 undefined reference to `typeinfo for SWIG_null_deleter'
 
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
 function `swig::traits_from::from(KIID const&)':
 

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Wayne Stambaugh]

I've been playing around with this and there is definetly something
amiss.  I don't get the build errors on release builds but I do see them
with debug builds (CMAKE_BUILD_TYPE=Debug).  Downgrading swig from
4.0.2-1 to 4.0.1-3 didn't help.  Interestingly the 5.1 branch builds
just fine so I suspect a recent change in the one of the CMake config
files is to blame.  I don't remember seeing any swig changes recently.

On 7/22/2020 9:30 AM, Brian Piccioni wrote:
> Using this script
> 
> cmake -DCMAKE_BUILD_TYPE=Debug -G "MSYS Makefiles"
> -DCMAKE_PREFIX_PATH=C:/msys64/mingw64
> -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64
> -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 -DMSYS=TRUE ../kicad
> 
> I get the same results
> 
> [ 98%] Built target qa_eeschema
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
> undefined reference to `.refptr.PyObject_GenericGetAttr'
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
> `std::invalid_argument::invalid_argument(std::invalid_argument const&)':
> C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined reference
> to `.refptr._ZTVSt16invalid_argument'
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
> `std::_Sp_counted_deleter std::allocator,
> (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
> C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
> undefined reference to `typeinfo for SWIG_null_deleter'
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
> `swig::traits_from::from(KIID const&)':
> C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929:
> undefined reference to `swig::traits_from_ptr::from(KIID*, int)'
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8):
> undefined reference to `typeinfo name for SWIG_null_deleter'
> collect2.exe: error: ld returned 1 exit status
> make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:634:
> pcbnew/_pcbnew.kiface] Error 1
> make[1]: *** [CMakeFiles/Makefile2:3284:
> pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2
> make: *** [Makefile:161: all] Error 2
> 
> bjpic@LAPTOP-70Q5CT1Q MINGW64 ~/FixedFormatting/clean/debug
> 
> On 2020-07-22 2:39 a.m., Nick Østergaard wrote:
>> Did you try to use the normal makefile generator rather than the
>> eclipse one?
>>
>> ons. 22. jul. 2020 01.37 skrev Brian Piccioni
>> mailto:br...@documenteddesigns.com>>:
>>
>> FWIW, I re-cloned Kicad master into an empty directory, created a
>> new build directory, ran the standard build script
>>
>> cmake -DCMAKE_BUILD_TYPE=Debug \
>> -G "Eclipse CDT4 - Unix Makefiles" \
>> -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
>> -DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
>> -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
>> -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
>> -DMSYS=TRUE \
>> ../kicad
>>
>> and got the same errors
>>
>>  Built target qa_eeschema
>> 
>> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> 
>> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
>> undefined reference to `.refptr.PyObject_GenericGetAttr'
>> 
>> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
>> function
>> `std::invalid_argument::invalid_argument(std::invalid_argument
>> const&)':
>> C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined
>> reference to `.refptr._ZTVSt16invalid_argument'
>> 
>> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
>> function `std::_Sp_counted_deleter> std::allocator,
>> (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
>> C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
>> undefined reference to `typeinfo for SWIG_null_deleter'
>> 
>> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
>> function `swig::traits_from::from(KIID const&)':
>> 
>> 

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Brian Piccioni]

Using this script

cmake -DCMAKE_BUILD_TYPE=Debug -G "MSYS Makefiles" 
-DCMAKE_PREFIX_PATH=C:/msys64/mingw64 
-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 
-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 -DMSYS=TRUE ../kicad


I get the same results

[ 98%] Built target qa_eeschema
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd): 
undefined reference to `.refptr.PyObject_GenericGetAttr'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function 
`std::invalid_argument::invalid_argument(std::invalid_argument const&)':
C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined reference 
to `.refptr._ZTVSt16invalid_argument'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function 
`std::_Sp_counted_deleterstd::allocator, 
(__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490: 
undefined reference to `typeinfo for SWIG_null_deleter'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function 
`swig::traits_from::from(KIID const&)':
C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929: 
undefined reference to `swig::traits_from_ptr::from(KIID*, int)'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8): 
undefined reference to `typeinfo name for SWIG_null_deleter'

collect2.exe: error: ld returned 1 exit status
make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:634: 
pcbnew/_pcbnew.kiface] Error 1
make[1]: *** [CMakeFiles/Makefile2:3284: 
pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2

make: *** [Makefile:161: all] Error 2

bjpic@LAPTOP-70Q5CT1Q MINGW64 ~/FixedFormatting/clean/debug

On 2020-07-22 2:39 a.m., Nick Østergaard wrote:
Did you try to use the normal makefile generator rather than the 
eclipse one?


ons. 22. jul. 2020 01.37 skrev Brian Piccioni 
mailto:br...@documenteddesigns.com>>:


FWIW, I re-cloned Kicad master into an empty directory, created a
new build directory, ran the standard build script

cmake -DCMAKE_BUILD_TYPE=Debug \
-G "Eclipse CDT4 - Unix Makefiles" \
-DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
-DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
-DMSYS=TRUE \
../kicad

and got the same errors

 Built target qa_eeschema

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:

CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
undefined reference to `.refptr.PyObject_GenericGetAttr'

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
function
`std::invalid_argument::invalid_argument(std::invalid_argument
const&)':
C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined
reference to `.refptr._ZTVSt16invalid_argument'

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
function `std::_Sp_counted_deleter,
(__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
undefined reference to `typeinfo for SWIG_null_deleter'

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
function `swig::traits_from::from(KIID const&)':

C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929:
undefined reference to `swig::traits_from_ptr::from(KIID*, int)'

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:

CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8):
undefined reference to `typeinfo name for SWIG_null_deleter'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:635:
pcbnew/_pcbnew.kiface] Error 1
make[1]: *** [CMakeFiles/Makefile2:3284:
pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2
make: *** 

Re: [Kicad-developers] Output Generation automation

[f . corona]

‌

‌Hi 
all,

I completed the document to a point where I am unlikely to change it change it 
on my own, without your feedback.
What is the usual way for a document to be reviewed, and hopefully to make its 
way as a specification document ?

Should I create a MR on gitlab for discussion ?


Here is the link to the document:
https://docs.google.com/document/d/1LG-S1c7BfGrXj_r0ITTi80kftTeIIJPo4zKom7jv4U4/edit?usp=sharing;
 
rel="nofollow">https://docs.google.com/document/d/1LG-S1c7BfGrXj_r0ITTi80kftTeIIJPo4zKom7jv4U4/edit?usp=sharing

Regards,

Fabien Corona




To: mailto:kicad-developers@DOMAIN.HIDDEN;>kicad-developers@xxx
From: Fabien Corona mailto:f.corona@DOMAIN.HIDDEN;>f.corona@xxx
Date: Sat, 18 Jul 2020 23:28:40 
+0200
User-agent: Mozilla/5.0 (X11; 
Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0


Hi all,


In regards with issue #2346, I think Kicad users would highly benefit
from an output automation.

https://gitlab.com/kicad/code/kicad/-/issues/2346; 
rel="nofollow">https://gitlab.com/kicad/code/kicad/-/issues/2346


I know some work already has been done with plugins like Kiplot (
https://github.com/johnbeard/kiplot; 
rel="nofollow">https://github.com/johnbeard/kiplot ) , but I think Kicad 
should have
its own automated output generation.

I do not know if someone already started to specify how something like
this should work, but I started a document:

https://docs.google.com/document/d/1LG-S1c7BfGrXj_r0ITTi80kftTeIIJPo4zKom7jv4U4/edit?usp=sharing;
 
rel="nofollow">https://docs.google.com/document/d/1LG-S1c7BfGrXj_r0ITTi80kftTeIIJPo4zKom7jv4U4/edit?usp=sharing


This document describes how the user could use the automated output
generation, and provides some visuals. It does not describe how it
should work under the hood ( storing information in files, how the
plotting tools connect,... ).

It deals with user interface.


If you have any comment about the document, please add them to the
document. If you know any other document that deals with this matter, I
would love to have a link to it.

If we get to something that satisfies (almost ?) everybody, we could
then add some implementation notes, and hopefully we could have
something working for V6.


Kicadly yours,

Fabien Corona





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Brian Piccioni]

I'll try it now but but the makefile generator script I used worked fine 
for over a year until now.


On 2020-07-22 2:39 a.m., Nick Østergaard wrote:
Did you try to use the normal makefile generator rather than the 
eclipse one?


ons. 22. jul. 2020 01.37 skrev Brian Piccioni 
mailto:br...@documenteddesigns.com>>:


FWIW, I re-cloned Kicad master into an empty directory, created a
new build directory, ran the standard build script

cmake -DCMAKE_BUILD_TYPE=Debug \
-G "Eclipse CDT4 - Unix Makefiles" \
-DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
-DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
-DMSYS=TRUE \
../kicad

and got the same errors

 Built target qa_eeschema

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:

CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
undefined reference to `.refptr.PyObject_GenericGetAttr'

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
function
`std::invalid_argument::invalid_argument(std::invalid_argument
const&)':
C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined
reference to `.refptr._ZTVSt16invalid_argument'

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
function `std::_Sp_counted_deleter,
(__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
undefined reference to `typeinfo for SWIG_null_deleter'

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
function `swig::traits_from::from(KIID const&)':

C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929:
undefined reference to `swig::traits_from_ptr::from(KIID*, int)'

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:

CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8):
undefined reference to `typeinfo name for SWIG_null_deleter'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:635:
pcbnew/_pcbnew.kiface] Error 1
make[1]: *** [CMakeFiles/Makefile2:3284:
pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2
make: *** [Makefile:161: all] Error 2

bjpic@LAPTOP-70Q5CT1Q MINGW64 ~/FixedFormatting/clean/debug
$



On 2020-07-21 2:54 p.m., Ian McInerney wrote:

Ignore all of those notes being printed by the compiler about
mismatched struct/class definition. There is a bug in GCC 10.1
that isn't silencing those properly, but that is fixed in GCC
10.2/GCC 11 (I think they are hoping to release 10.2 this week).

The linker errors appear to be Python related. Did you update
your Python installation that KiCad uses recently? Can you
confirm that SWIG and Python are being detected correctly bby CMake?

-Ian

On Tue, Jul 21, 2020 at 6:58 PM Brian Piccioni
mailto:br...@documenteddesigns.com>> wrote:

Before updating master I had successfuIly build a c late June
version.

After failing to build yesterday's master I deleted my build
directory, pulled master, same problem. I then updated msys
in order to make sure it wasn't a tool issue. Same problem. I
deleted the build directory and same result.

When I get home I'll try a new download of master and try
that but I expect the same result

Note the earlier reply claiming to have had a similar problem.

On Tue, Jul 21, 2020, 13:47 Nick Østergaard
mailto:oe.n...@gmail.com>> wrote:

That looks quite strange. Did you try a clean build
directort? Maybe
there is some caching that is broken after a toolchain
update?  Pure
speculation.


On Tue, 21 Jul 2020 at 16:47, Brian Piccioni
mailto:br...@documenteddesigns.com>> wrote:
>
> It is a non-release tag, but as a developer I sort of
need it to compile ...
>
> On 2020-07-21 10:45 a.m., Alex wrote:
>
> I too, also had the same errors, but assumed that 5.99
was some weird non-release tag, and switched to a
different branch, as this is my first day building the
application.
>
> On Tue, Jul 21, 2020, 4:42 PM Brian Piccioni
 

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Nick Østergaard]

Did you try to use the normal makefile generator rather than the eclipse
one?

ons. 22. jul. 2020 01.37 skrev Brian Piccioni :

> FWIW, I re-cloned Kicad master into an empty directory, created a new
> build directory, ran the standard build script
>
> cmake -DCMAKE_BUILD_TYPE=Debug \
> -G "Eclipse CDT4 - Unix Makefiles" \
> -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
> -DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
> -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
> -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
> -DMSYS=TRUE \
> ../kicad
>
> and got the same errors
>
>  Built target qa_eeschema
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
> undefined reference to `.refptr.PyObject_GenericGetAttr'
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
> `std::invalid_argument::invalid_argument(std::invalid_argument const&)':
> C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined reference to
> `.refptr._ZTVSt16invalid_argument'
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
> `std::_Sp_counted_deleter std::allocator,
> (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
> C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490: undefined
> reference to `typeinfo for SWIG_null_deleter'
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
> `swig::traits_from::from(KIID const&)':
> C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929:
> undefined reference to `swig::traits_from_ptr::from(KIID*, int)'
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8):
> undefined reference to `typeinfo name for SWIG_null_deleter'
> collect2.exe: error: ld returned 1 exit status
> make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:635:
> pcbnew/_pcbnew.kiface] Error 1
> make[1]: *** [CMakeFiles/Makefile2:3284:
> pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2
> make: *** [Makefile:161: all] Error 2
>
> bjpic@LAPTOP-70Q5CT1Q MINGW64 ~/FixedFormatting/clean/debug
> $
>
>
>
> On 2020-07-21 2:54 p.m., Ian McInerney wrote:
>
> Ignore all of those notes being printed by the compiler about mismatched
> struct/class definition. There is a bug in GCC 10.1 that isn't silencing
> those properly, but that is fixed in GCC 10.2/GCC 11 (I think they are
> hoping to release 10.2 this week).
>
> The linker errors appear to be Python related. Did you update your Python
> installation that KiCad uses recently? Can you confirm that SWIG and Python
> are being detected correctly bby CMake?
>
> -Ian
>
> On Tue, Jul 21, 2020 at 6:58 PM Brian Piccioni <
> br...@documenteddesigns.com> wrote:
>
>> Before updating master I had successfuIly build a c late June version.
>>
>> After failing to build yesterday's master I deleted my build directory,
>> pulled master, same problem. I then updated msys in order to make sure it
>> wasn't a tool issue. Same problem. I deleted the build directory and same
>> result.
>>
>> When I get home I'll try a new download of master and try that but I
>> expect the same result
>>
>> Note the earlier reply claiming to have had a similar problem.
>>
>> On Tue, Jul 21, 2020, 13:47 Nick Østergaard  wrote:
>>
>>> That looks quite strange. Did you try a clean build directort? Maybe
>>> there is some caching that is broken after a toolchain update?  Pure
>>> speculation.
>>>
>>>
>>> On Tue, 21 Jul 2020 at 16:47, Brian Piccioni
>>>  wrote:
>>> >
>>> > It is a non-release tag, but as a developer I sort of need it to
>>> compile ...
>>> >
>>> > On 2020-07-21 10:45 a.m., Alex wrote:
>>> >
>>> > I too, also had the same errors, but assumed that 5.99 was some weird
>>> non-release tag, and switched to a different branch, as this is my first
>>> day building the application.
>>> >
>>> > On Tue, Jul 21, 2020, 4:42 PM Brian Piccioni <
>>> br...@documenteddesigns.com> wrote:
>>> >>
>>> >> When building I get a slew of errors or information messages of the
>>> type
>>> >> (see below). During linking I then get a pile of "undefined" errors.
>>> >> There are so many I can't reproduce them all.
>>> >>
>>> >> When I link I get a fatal error.
>>> >>
>>> >> This is the Master branch downloaded a few minutes before compiling. I
>>> >> tried updating Msys and get the same result.
>>> >>
>>> >>
>>> >> 42 |   struct ctype_base
>>> >>|  ^~
>>> >> In file included from