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

[Brian Piccioni]

Thanks for the headsup. Compile is much cleaner now.

FYI I seem to recall the issue had an indirect relationship to Python 
and I note Msys upgraded Python when I ran Pacman -Syuu so perhaps that 
had something to do with it working?



On 2020-07-25 8:25 a.m., Wayne Stambaugh wrote:

As of commit 33af2d9a, debug builds started working agian even though I
didn't see anything that would have fixed this issue.

The msys2 project just released gcc 10.2 which gets rid of all of the
warning messages so you should probably upgrade when you get a chance.

On 7/24/2020 8:05 PM, Brian Piccioni wrote:

FWIW I realized that I didn't need a debug version of the code in order
to resolve my merge issues so I built a Release version with no troubles.

In a way I'm glad I reported this because it could have been a problem
later on and at least the people who know what SWIG is and can do
something about it are aware.

On 2020-07-24 5:00 p.m., Wayne Stambaugh wrote:

It's probably too late to tell swig not to wrap everything.  We should
have only wrapped the objects that we wanted to expose to scripting
langauages but that is a lot more work.  That being said, swig only
wraps what we tell it to wrap so if we don't want something wrapped then
we need to let swig know.  If you include a new header an existing
header that gets pull in than you have to tell swig to exclude it.

On 7/24/2020 4:11 PM, Jon Evans wrote:

I am not sure the exact nature of this error, but it seems like somehow
SWIG is failing to wrap some data structures.

Since we are planning on the new Python API not just exposing all
internals, maybe instead of trying to debug SWIG we should just start
restricting it to not wrap everything?


On Fri, Jul 24, 2020 at 4:04 PM Wayne Stambaugh mailto:stambau...@gmail.com>> wrote:

  I filed a issue[1] for this.  Just to add insult to injury,
clang wont
  work because something changed in libcontext that causes it to
choke.
  The hits just keep on coming.

  [1]: https://gitlab.com/kicad/code/kicad/-/issues/4967

  On 7/22/2020 6:39 PM, Jon Evans wrote:
  > 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
  mailto:stambau...@gmail.com>
  > >>
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
  >     mailto:stambau...@gmail.com>
  >
  >     > 
       >
  >     >     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>
  >     >
  >     
  >     >>
  >     >     
  >     >
  >     >     

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

[Wayne Stambaugh]

As of commit 33af2d9a, debug builds started working agian even though I
didn't see anything that would have fixed this issue.

The msys2 project just released gcc 10.2 which gets rid of all of the
warning messages so you should probably upgrade when you get a chance.

On 7/24/2020 8:05 PM, Brian Piccioni wrote:
> FWIW I realized that I didn't need a debug version of the code in order
> to resolve my merge issues so I built a Release version with no troubles.
> 
> In a way I'm glad I reported this because it could have been a problem
> later on and at least the people who know what SWIG is and can do
> something about it are aware.
> 
> On 2020-07-24 5:00 p.m., Wayne Stambaugh wrote:
>> It's probably too late to tell swig not to wrap everything.  We should
>> have only wrapped the objects that we wanted to expose to scripting
>> langauages but that is a lot more work.  That being said, swig only
>> wraps what we tell it to wrap so if we don't want something wrapped then
>> we need to let swig know.  If you include a new header an existing
>> header that gets pull in than you have to tell swig to exclude it.
>>
>> On 7/24/2020 4:11 PM, Jon Evans wrote:
>>> I am not sure the exact nature of this error, but it seems like somehow
>>> SWIG is failing to wrap some data structures.
>>>
>>> Since we are planning on the new Python API not just exposing all
>>> internals, maybe instead of trying to debug SWIG we should just start
>>> restricting it to not wrap everything?
>>>
>>>
>>> On Fri, Jul 24, 2020 at 4:04 PM Wayne Stambaugh >> > wrote:
>>>
>>>  I filed a issue[1] for this.  Just to add insult to injury,
>>> clang wont
>>>  work because something changed in libcontext that causes it to
>>> choke.
>>>  The hits just keep on coming.
>>>
>>>  [1]: https://gitlab.com/kicad/code/kicad/-/issues/4967
>>>
>>>  On 7/22/2020 6:39 PM, Jon Evans wrote:
>>>  > 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
>>>  mailto:stambau...@gmail.com>
>>>  > >>
>>> 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
>>>  >     mailto:stambau...@gmail.com>
>>>  >
>>>  >     > 
>>>  >> 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
>>>  >     >     > >>  
>>>  >     >>  >
>>>  >     >>  
>>>  >     >>  >>
>>>  >     >     >>  
>>>  >     >>  

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

[Brian Piccioni]

FWIW I realized that I didn't need a debug version of the code in order 
to resolve my merge issues so I built a Release version with no troubles.


In a way I'm glad I reported this because it could have been a problem 
later on and at least the people who know what SWIG is and can do 
something about it are aware.


On 2020-07-24 5:00 p.m., Wayne Stambaugh wrote:

It's probably too late to tell swig not to wrap everything.  We should
have only wrapped the objects that we wanted to expose to scripting
langauages but that is a lot more work.  That being said, swig only
wraps what we tell it to wrap so if we don't want something wrapped then
we need to let swig know.  If you include a new header an existing
header that gets pull in than you have to tell swig to exclude it.

On 7/24/2020 4:11 PM, Jon Evans wrote:

I am not sure the exact nature of this error, but it seems like somehow
SWIG is failing to wrap some data structures.

Since we are planning on the new Python API not just exposing all
internals, maybe instead of trying to debug SWIG we should just start
restricting it to not wrap everything?


On Fri, Jul 24, 2020 at 4:04 PM Wayne Stambaugh mailto:stambau...@gmail.com>> wrote:

 I filed a issue[1] for this.  Just to add insult to injury, clang wont
 work because something changed in libcontext that causes it to choke.
 The hits just keep on coming.

 [1]: https://gitlab.com/kicad/code/kicad/-/issues/4967

 On 7/22/2020 6:39 PM, Jon Evans wrote:
 > 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
 mailto:stambau...@gmail.com>
 > >> 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
 >     mailto:stambau...@gmail.com>
 >
 >     > 
      >
 >     >     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 

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

[Wayne Stambaugh]

It's probably too late to tell swig not to wrap everything.  We should
have only wrapped the objects that we wanted to expose to scripting
langauages but that is a lot more work.  That being said, swig only
wraps what we tell it to wrap so if we don't want something wrapped then
we need to let swig know.  If you include a new header an existing
header that gets pull in than you have to tell swig to exclude it.

On 7/24/2020 4:11 PM, Jon Evans wrote:
> I am not sure the exact nature of this error, but it seems like somehow
> SWIG is failing to wrap some data structures.
> 
> Since we are planning on the new Python API not just exposing all
> internals, maybe instead of trying to debug SWIG we should just start
> restricting it to not wrap everything?
> 
> 
> On Fri, Jul 24, 2020 at 4:04 PM Wayne Stambaugh  > wrote:
> 
> I filed a issue[1] for this.  Just to add insult to injury, clang wont
> work because something changed in libcontext that causes it to choke.
> The hits just keep on coming.
> 
> [1]: https://gitlab.com/kicad/code/kicad/-/issues/4967
> 
> On 7/22/2020 6:39 PM, Jon Evans wrote:
> > 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
> mailto:stambau...@gmail.com>
> > >> 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
> >     mailto:stambau...@gmail.com>
> >
> >     > 
>  >     >
> >     >     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
> >     >     >  
> >      >
> >      
> >      >>
> >     >      
> >      >
> >     >      
> >       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
> >     >     >     >  

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

[Wayne Stambaugh]

I filed a issue[1] for this.  Just to add insult to injury, clang wont
work because something changed in libcontext that causes it to choke.
The hits just keep on coming.

[1]: https://gitlab.com/kicad/code/kicad/-/issues/4967

On 7/22/2020 6:39 PM, Jon Evans wrote:
> 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
> mailto:stambau...@gmail.com>
> > >> 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
> >     >  
>  >
> >      
> >       >     >
> >     >     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
> >     >     
> >     >    

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

[jp charras]

Le 23/07/2020 à 00:39, Jon Evans a écrit :
> 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.
> 

I tested a build on my W7 32bits install, with a recent msys2 version
(not the latest):

Application: KiCad

Version: (5.99.0-2385-g7067e42da-dirty), debug build

Libraries:
wxWidgets 3.1.3
libcurl/7.65.1 OpenSSL/1.1.1c (Schannel) zlib/1.2.11 brotli/1.0.7
libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.39.1

Platform: Windows 7 (build 7601, Service Pack 1), 32 bit, Little endian,
wxMSW

Build Info:
Date: Jul 23 2020 08:48:19
wxWidgets: 3.1.3 (wchar_t,wx containers)
Boost: 1.73.0
OCE: 6.9.1
Curl: 7.70.0
ngspice: 31+
Compiler: GCC 10.1.0 with C++ ABI 1014

Build settings:
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=OFF
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=OFF
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_SPICE=ON
KICAD_STDLIB_DEBUG=OFF
KICAD_STDLIB_LIGHT_DEBUG=OFF
KICAD_SANITIZE=OFF


My swig version is 4.01.

I have the lot of compil warnings, but I do not have the link issue.

-- 
Jean-Pierre CHARRAS

___
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

[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] 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 

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

[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_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: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
mailto: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 

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

[Ian McInerney]

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 
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 C:/msys64/mingw64/include/c++/10.1.0/string:43,
>> >>   from
>> C:/msys64/mingw64/include/wx-3.0/wx/stringimpl.h:66,
>> >>   from
>> C:/msys64/mingw64/include/wx-3.0/wx/unichar.h:15,
>> >>   from
>> C:/msys64/mingw64/include/wx-3.0/wx/strvararg.h:22,
>> >>   from C:/msys64/mingw64/include/wx-3.0/wx/string.h:46,
>> >>   from C:/msys64/mingw64/include/wx-3.0/wx/memory.h:15,
>> >>   from C:/msys64/mingw64/include/wx-3.0/wx/object.h:19,
>> >>   from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:15,
>> >>   from
>> >> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
>> >>   from
>> >>
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
>> >> C:/msys64/mingw64/include/c++/10.1.0/bits/localefwd.h:125:9: note:
>> >> replace the class-key with 'struct'
>> >>125 |   class ctype_base;
>> >>| ^~
>> >> In file included from
>> >> C:/msys64/mingw64/include/c++/10.1.0/bits/locale_facets.h:41,
>> >>   from
>> >> C:/msys64/mingw64/include/c++/10.1.0/bits/basic_ios.h:37,
>> >>   from C:/msys64/mingw64/include/c++/10.1.0/ios:44,
>> >>   from C:/msys64/mingw64/include/c++/10.1.0/ostream:38,
>> >>   from
>> C:/msys64/mingw64/include/c++/10.1.0/iostream:39,
>> >>   from
>> C:/msys64/mingw64/include/wx-3.0/wx/ioswrap.h:18,
>> >>   from
>> C:/msys64/mingw64/include/wx-3.0/wx/textctrl.h:33,
>> >>   from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:81,
>> >>   from
>> >> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
>> >>   from
>> >>
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
>> >>
>> C:/msys64/mingw64/include/c++/10.1.0/x86_64-w64-mingw32/bits/ctype_base.h:42:10:
>> >> note: 'std::ctype_base' defined as 'struct' here
>> >> 42 |   struct ctype_base
>> >>|  ^~
>> >> [ 93%] Building CXX object
>> >> pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/initpcb.cpp.obj
>> >> In file included from
>> >>
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/thirdparty/nlohmann_json/nlohmann/json.hpp:70,
>> >>   from
>> >>
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/json_settings.h:24,
>> >>   from
>> >>
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/app_settings.h:25,
>> >>   from
>> >>
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/pcbnew_settings.h:24,
>> >>   from
>> >>
>> 

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

[Brian Piccioni]

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 C:/msys64/mingw64/include/c++/10.1.0/string:43,
> >>   from
> C:/msys64/mingw64/include/wx-3.0/wx/stringimpl.h:66,
> >>   from C:/msys64/mingw64/include/wx-3.0/wx/unichar.h:15,
> >>   from
> C:/msys64/mingw64/include/wx-3.0/wx/strvararg.h:22,
> >>   from C:/msys64/mingw64/include/wx-3.0/wx/string.h:46,
> >>   from C:/msys64/mingw64/include/wx-3.0/wx/memory.h:15,
> >>   from C:/msys64/mingw64/include/wx-3.0/wx/object.h:19,
> >>   from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:15,
> >>   from
> >> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
> >>   from
> >>
> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
> >> C:/msys64/mingw64/include/c++/10.1.0/bits/localefwd.h:125:9: note:
> >> replace the class-key with 'struct'
> >>125 |   class ctype_base;
> >>| ^~
> >> In file included from
> >> C:/msys64/mingw64/include/c++/10.1.0/bits/locale_facets.h:41,
> >>   from
> >> C:/msys64/mingw64/include/c++/10.1.0/bits/basic_ios.h:37,
> >>   from C:/msys64/mingw64/include/c++/10.1.0/ios:44,
> >>   from C:/msys64/mingw64/include/c++/10.1.0/ostream:38,
> >>   from C:/msys64/mingw64/include/c++/10.1.0/iostream:39,
> >>   from C:/msys64/mingw64/include/wx-3.0/wx/ioswrap.h:18,
> >>   from
> C:/msys64/mingw64/include/wx-3.0/wx/textctrl.h:33,
> >>   from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:81,
> >>   from
> >> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
> >>   from
> >>
> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
> >>
> C:/msys64/mingw64/include/c++/10.1.0/x86_64-w64-mingw32/bits/ctype_base.h:42:10:
> >> note: 'std::ctype_base' defined as 'struct' here
> >> 42 |   struct ctype_base
> >>|  ^~
> >> [ 93%] Building CXX object
> >> pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/initpcb.cpp.obj
> >> In file included from
> >>
> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/thirdparty/nlohmann_json/nlohmann/json.hpp:70,
> >>   from
> >>
> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/json_settings.h:24,
> >>   from
> >>
> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/app_settings.h:25,
> >>   from
> >>
> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/pcbnew_settings.h:24,
> >>   from
> >>
> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/dialog_update_pcb.cpp:29:
> >> C:/msys64/mingw64/include/c++/10.1.0/valarray:574:20: note: replace the
> >> class-key with 'struct'
> >>574 |   friend class _Array<_Tp>;
> >>|^~~
> >> In file included from C:/msys64/mingw64/include/c++/10.1.0/valarray:100,
> >>   from
> >>
> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/thirdparty/nlohmann_json/nlohmann/json.hpp:70,
> >>   from
> >>
> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/json_settings.h:24,
> >>   from
> >>
> 

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

[Nick Østergaard]

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  
> 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 C:/msys64/mingw64/include/c++/10.1.0/string:43,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/stringimpl.h:66,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/unichar.h:15,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/strvararg.h:22,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/string.h:46,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/memory.h:15,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/object.h:19,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:15,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
>> C:/msys64/mingw64/include/c++/10.1.0/bits/localefwd.h:125:9: note:
>> replace the class-key with 'struct'
>>125 |   class ctype_base;
>>| ^~
>> In file included from
>> C:/msys64/mingw64/include/c++/10.1.0/bits/locale_facets.h:41,
>>   from
>> C:/msys64/mingw64/include/c++/10.1.0/bits/basic_ios.h:37,
>>   from C:/msys64/mingw64/include/c++/10.1.0/ios:44,
>>   from C:/msys64/mingw64/include/c++/10.1.0/ostream:38,
>>   from C:/msys64/mingw64/include/c++/10.1.0/iostream:39,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/ioswrap.h:18,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/textctrl.h:33,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:81,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
>> C:/msys64/mingw64/include/c++/10.1.0/x86_64-w64-mingw32/bits/ctype_base.h:42:10:
>> note: 'std::ctype_base' defined as 'struct' here
>> 42 |   struct ctype_base
>>|  ^~
>> [ 93%] Building CXX object
>> pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/initpcb.cpp.obj
>> In file included from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/thirdparty/nlohmann_json/nlohmann/json.hpp:70,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/json_settings.h:24,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/app_settings.h:25,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/pcbnew_settings.h:24,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/dialog_update_pcb.cpp:29:
>> C:/msys64/mingw64/include/c++/10.1.0/valarray:574:20: note: replace the
>> class-key with 'struct'
>>574 |   friend class _Array<_Tp>;
>>|^~~
>> In file included from C:/msys64/mingw64/include/c++/10.1.0/valarray:100,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/thirdparty/nlohmann_json/nlohmann/json.hpp:70,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/json_settings.h:24,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/app_settings.h:25,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/pcbnew_settings.h:24,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/dialog_update_pcb.cpp:29:
>> C:/msys64/mingw64/include/c++/10.1.0/bits/valarray_array.h:396:12: note:
>> 'std::_Array<_Tp>' defined as 'struct' here
>>396 | struct _Array
>>|^~
>> In file included from
>> C:/msys64/mingw64/include/c++/10.1.0/bits/ios_base.h:46,
>>   from C:/msys64/mingw64/include/c++/10.1.0/streambuf:41,
>>   from
>> C:/msys64/mingw64/include/c++/10.1.0/bits/streambuf_iterator.h:35,
>>  

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

[Brian Piccioni]

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 
mailto: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 C:/msys64/mingw64/include/c++/10.1.0/string:43,
  from
C:/msys64/mingw64/include/wx-3.0/wx/stringimpl.h:66,
  from
C:/msys64/mingw64/include/wx-3.0/wx/unichar.h:15,
  from
C:/msys64/mingw64/include/wx-3.0/wx/strvararg.h:22,
  from
C:/msys64/mingw64/include/wx-3.0/wx/string.h:46,
  from
C:/msys64/mingw64/include/wx-3.0/wx/memory.h:15,
  from
C:/msys64/mingw64/include/wx-3.0/wx/object.h:19,
  from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:15,
  from
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
C:/msys64/mingw64/include/c++/10.1.0/bits/localefwd.h:125:9: note:
replace the class-key with 'struct'
   125 |   class ctype_base;
   | ^~
In file included from
C:/msys64/mingw64/include/c++/10.1.0/bits/locale_facets.h:41,
  from
C:/msys64/mingw64/include/c++/10.1.0/bits/basic_ios.h:37,
  from C:/msys64/mingw64/include/c++/10.1.0/ios:44,
  from
C:/msys64/mingw64/include/c++/10.1.0/ostream:38,
  from
C:/msys64/mingw64/include/c++/10.1.0/iostream:39,
  from
C:/msys64/mingw64/include/wx-3.0/wx/ioswrap.h:18,
  from
C:/msys64/mingw64/include/wx-3.0/wx/textctrl.h:33,
  from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:81,
  from
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:

C:/msys64/mingw64/include/c++/10.1.0/x86_64-w64-mingw32/bits/ctype_base.h:42:10:

note: 'std::ctype_base' defined as 'struct' here
    42 |   struct ctype_base
   |  ^~
[ 93%] Building CXX object
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/initpcb.cpp.obj
In file included from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/thirdparty/nlohmann_json/nlohmann/json.hpp:70,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/json_settings.h:24,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/app_settings.h:25,
  from
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/pcbnew_settings.h:24,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/dialog_update_pcb.cpp:29:
C:/msys64/mingw64/include/c++/10.1.0/valarray:574:20: note:
replace the
class-key with 'struct'
   574 |   friend class _Array<_Tp>;
   |    ^~~
In file included from
C:/msys64/mingw64/include/c++/10.1.0/valarray:100,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/thirdparty/nlohmann_json/nlohmann/json.hpp:70,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/json_settings.h:24,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/app_settings.h:25,
  from
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/pcbnew_settings.h:24,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/dialog_update_pcb.cpp:29:
C:/msys64/mingw64/include/c++/10.1.0/bits/valarray_array.h:396:12:
note:
'std::_Array<_Tp>' defined as 'struct' here
   396 | struct _Array
   |    ^~
In file included from
C:/msys64/mingw64/include/c++/10.1.0/bits/ios_base.h:46,
  from
C:/msys64/mingw64/include/c++/10.1.0/streambuf:41,
  from
C:/msys64/mingw64/include/c++/10.1.0/bits/streambuf_iterator.h:35,
  from

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

[Brian Piccioni]

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 C:/msys64/mingw64/include/c++/10.1.0/string:43,
 from C:/msys64/mingw64/include/wx-3.0/wx/stringimpl.h:66,
 from C:/msys64/mingw64/include/wx-3.0/wx/unichar.h:15,
 from C:/msys64/mingw64/include/wx-3.0/wx/strvararg.h:22,
 from C:/msys64/mingw64/include/wx-3.0/wx/string.h:46,
 from C:/msys64/mingw64/include/wx-3.0/wx/memory.h:15,
 from C:/msys64/mingw64/include/wx-3.0/wx/object.h:19,
 from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:15,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
C:/msys64/mingw64/include/c++/10.1.0/bits/localefwd.h:125:9: note: 
replace the class-key with 'struct'

  125 |   class ctype_base;
  | ^~
In file included from 
C:/msys64/mingw64/include/c++/10.1.0/bits/locale_facets.h:41,
 from 
C:/msys64/mingw64/include/c++/10.1.0/bits/basic_ios.h:37,

 from C:/msys64/mingw64/include/c++/10.1.0/ios:44,
 from C:/msys64/mingw64/include/c++/10.1.0/ostream:38,
 from C:/msys64/mingw64/include/c++/10.1.0/iostream:39,
 from C:/msys64/mingw64/include/wx-3.0/wx/ioswrap.h:18,
 from C:/msys64/mingw64/include/wx-3.0/wx/textctrl.h:33,
 from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:81,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
C:/msys64/mingw64/include/c++/10.1.0/x86_64-w64-mingw32/bits/ctype_base.h:42:10: 
note: 'std::ctype_base' defined as 'struct' here

   42 |   struct ctype_base
  |  ^~
[ 93%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/initpcb.cpp.obj
In file included from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/thirdparty/nlohmann_json/nlohmann/json.hpp:70,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/json_settings.h:24,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/app_settings.h:25,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/pcbnew_settings.h:24,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/dialog_update_pcb.cpp:29:
C:/msys64/mingw64/include/c++/10.1.0/valarray:574:20: note: replace the 
class-key with 'struct'

  574 |   friend class _Array<_Tp>;
  |    ^~~
In file included from C:/msys64/mingw64/include/c++/10.1.0/valarray:100,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/thirdparty/nlohmann_json/nlohmann/json.hpp:70,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/json_settings.h:24,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/app_settings.h:25,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/pcbnew_settings.h:24,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/dialog_update_pcb.cpp:29:
C:/msys64/mingw64/include/c++/10.1.0/bits/valarray_array.h:396:12: note: 
'std::_Array<_Tp>' defined as 'struct' here

  396 | struct _Array
  |    ^~
In file included from 
C:/msys64/mingw64/include/c++/10.1.0/bits/ios_base.h:46,

 from C:/msys64/mingw64/include/c++/10.1.0/streambuf:41,
 from 
C:/msys64/mingw64/include/c++/10.1.0/bits/streambuf_iterator.h:35,

 from C:/msys64/mingw64/include/c++/10.1.0/iterator:66,
 from C:/msys64/mingw64/include/c++/10.1.0/regex:43,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_pcbnew_color_settings.cpp:21:
C:/msys64/mingw64/include/c++/10.1.0/system_error:54:9: note: replace 
the class-key with 'struct'

   54 |   class error_code;
  | ^~
C:/msys64/mingw64/include/c++/10.1.0/system_error:180:10: note: 
'std::error_code' defined as 'struct' here

  180 |   struct error_code
  |  ^~
C:/msys64/mingw64/include/c++/10.1.0/system_error:55:9: note: replace 
the class-key with 'struct'

   55 |   class error_condition;
  | ^~~
C:/msys64/mingw64/include/c++/10.1.0/system_error:278:10: note: 
'std::error_condition'