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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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 \
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
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
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
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
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
24 matches
Mail list logo
