[Kicad-developers] mingw64 C++11 status?

[Seth Hillbrand]

Hi Devs-

Does anyone know what our mingw64 g++ version for the nightly builds' 
support for C++11 is?  There are a few bug reports of odd locking 
behavior[1][2].  These seem to be when the user gets to the dynamic 
ratsnest update.


So, thinking that our use of atomic might be problematic, I've adjusted 
this a few times, finally going to std::async with std::futures 
promises.  This seems to have cleared the issue for [1] but made [2] 
worse.


Both std::async and std::future have been supported on Linux gcc since 
at least 4.7 but I've read in a few places [3][4] that it might not work 
in mingw64.  I can't seem to find a list of supported features anywhere. 
 Does anyone have a reference?


-Seth

[1] https://bugs.launchpad.net/kicad/+bug/1795951
[2] https://bugs.launchpad.net/kicad/+bug/1798460
[3] 
https://stackoverflow.com/questions/10209871/c11-stdasync-doesnt-work-in-mingw

[4] https://github.com/meganz/mingw-std-threads/issues/17

___
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] Separated debug symbols

[Simon Richter]

Hi,

On 26.10.2018 22:18, Maciej Suminski wrote:

> I have not pushed the patch yet, as I still wonder whether adding
> another CMake flag is a good idea. Just now I realized that there are
> just a few extra commands to create the needed files, so perhaps they
> could be executed by the build scripts on Jenkins hosts.

Ideally, we'd always build separate debug info with Debug builds if the
toolchain supports it. So, no need for a separate option, I think.

On MSVC, separate debug info is already the default, so we should do
nothing there.

The GNU toolchain also has build IDs, which allows keeping multiple
versions of debug information, and


https://stackoverflow.com/questions/32861480/cmake-save-stripped-debug-information

has a nice fragment for that, although the build ID needs to be
generated somewhere (and distros need a way to pass them in for
reproducible builds). The ID would be accessible from the About dialog
as well so you know which debug package to download.

   Simon



signature.asc
Description: OpenPGP digital signature
___
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

[Kicad-developers] Jenkins build is back to normal : linux-kicad-full-gcc-head #4223

[Miguel Angel Ajo]

See 



___
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] eeschema depends on libngspice.so instead of libngspice.so.0?

[Stefan Brüns]

On Samstag, 27. Oktober 2018 00:12:21 CEST Carsten Schoenert wrote:
> As a potential step into the right direction it would be good if
> eeschema would search for libngspice.so.0 on Linux platforms. I can then
> add a manual dependency on the library package instead on the -dev
> package (which is gladly for ngspice rather small compared to other -dev
> packages).

See 
https://build.opensuse.org/package/view_file/electronics/kicad/0001-Use-fixed-version-for-libngspice.so.0.patch?expand=1
 for a patch ...

Kind regards,

Stefan

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019

signature.asc
Description: This is a digitally signed message part.
___
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] eeschema depends on libngspice.so instead of libngspice.so.0?

[Carsten Schoenert]

Hello Orson,

Am 26.10.18 um 22:30 schrieb Maciej Suminski:
> What about libngspice.so.0 symlink? Which package ships that? Anyway, it
> makes sense to request a particular version of the library in case the
> API changes in the future.

Simon already has written some more technical explanation but to answer
your question here in detail, libspice.so.0 is provided (for the reason
Simon mentioned) in the plain library package in Debian, and this is
libngspice0.

https://packages.debian.org/sid/amd64/libngspice0/filelist

>> So looking manually at the binaries build from the kicad source by ldd I
>> can see a lot linked libraries but no library libngspice.so.0! Seems the
>> library is simply opened by dlopen. So that's the reason why the
>> packaging isn't adding a dependency on the package libngspice0.
> 
> You are correct. The library used to be linked with eeschema, but we
> have faced problems that could be resolved only by reloading the
> library. I am afraid it has to stay this way for the time being.

As a potential step into the right direction it would be good if
eeschema would search for libngspice.so.0 on Linux platforms. I can then
add a manual dependency on the library package instead on the -dev
package (which is gladly for ngspice rather small compared to other -dev
packages).
nsgpice and especially the upstream packaging did from a Debain POV
really big steps forwards and I'm really happy that Holger from the
upstream team was really responsive to my questions and suggestions in
the past year! Without this it wouldn't be possible that KiCad in Debian
can now use ngspice from Debian main!

So far I know Holger is also reading on this list, so I suggest to get
in contact with Holger Vogt about the problems you have or had in the
past. I'm quite sure Holger is willing to improve the situation if possible.

-- 
Regards
Carsten Schoenert

___
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] eeschema depends on libngspice.so instead of libngspice.so.0?

[Stefan Brüns]

On Freitag, 26. Oktober 2018 22:30:03 CEST Maciej Suminski wrote:
> > $ dpkg -S /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0
> > 
> >> libngspice0:amd64: /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0
> 
> What about libngspice.so.0 symlink? Which package ships that? Anyway, it
> makes sense to request a particular version of the library in case the
> API changes in the future.
> 
> > So looking manually at the binaries build from the kicad source by ldd I
> > can see a lot linked libraries but no library libngspice.so.0! Seems the
> > library is simply opened by dlopen. So that's the reason why the
> > packaging isn't adding a dependency on the package libngspice0.
> 
> You are correct. The library used to be linked with eeschema, but we
> have faced problems that could be resolved only by reloading the
> library. I am afraid it has to stay this way for the time being.

The safest approach would be to create a shim library/module which links to 
libngspice.so.x at build time. Any API changes would be catched at build time 
and the soversion would be fixed afterwards.

Shipping this module as part KiCad would also make automatic dependency 
resolution work again.

Kind regards,

Stefan

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019

signature.asc
Description: This is a digitally signed message part.
___
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] eeschema depends on libngspice.so instead of libngspice.so.0?

[Simon Richter]

Hi,

On 26.10.2018 22:30, Maciej Suminski wrote:

> What about libngspice.so.0 symlink? Which package ships that? Anyway, it
> makes sense to request a particular version of the library in case the
> API changes in the future.

The .so.0 symlink is created from the SONAME field in the library. This
is the correct way to reference a library by ABI.

> You are correct. The library used to be linked with eeschema, but we
> have faced problems that could be resolved only by reloading the
> library. I am afraid it has to stay this way for the time being.

The packaging tools look for hard dependencies between ELF objects.
Anything else needs to be specified explicitly (which is totally
allowed). Do the SPICE people know about the problems?

   Simon



signature.asc
Description: OpenPGP digital signature
___
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] eeschema depends on libngspice.so instead of libngspice.so.0?

[Maciej Suminski]

Hi Carsten,

On 10/26/18 9:22 PM, Carsten Schoenert wrote:
> Hi,
> 
> I got a bug report [1] for KiCad in Debian testing/unstable because of a
> not working ngspice based simulation in eeschema.
> 
> I was first searching for the reason why the packaging isn't detecting
> that the assumed library libngspice.so.0.0.0 was detected as a dependency.
> The bugreporter stated that he is needed the package libnsgpice0-dev to
> get eeschema working with simulation. So I tried around this information
> and the reporter is right. If I start eeschema without this package
> installed I get an error message that libngspice.so was not found.
> 
> This is an error in my eyes because eeschema is not looking for the
> needed library with the API version it's build against. As libngspice is
> using a API version 0 the correct library to look for would be
> libngspice.so.0 and not libngspice.so that is normally a symlink to the
> most recent version of the library and only used while linking.
> Thus we ship -dev packages in Debian with a symlink of a file libfoo.so
> to full versioned named library. For libngspice0 this looks like this:
> 
>> $ ls -l /usr/lib/x86_64-linux-gnu/libngspice.so*
>> lrwxrwxrwx 1 root root  19 Okt 15 19:50 
>> /usr/lib/x86_64-linux-gnu/libngspice.so -> libngspice.so.0.0.0
>> lrwxrwxrwx 1 root root  19 Okt 15 19:50 
>> /usr/lib/x86_64-linux-gnu/libngspice.so.0 -> libngspice.so.0.0.0
>> -rw-r--r-- 1 root root 7091024 Okt 15 19:50 
>> /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0
> 
>> $ dpkg -S /usr/lib/x86_64-linux-gnu/libngspice.so
>> libngspice0-dev:amd64: /usr/lib/x86_64-linux-gnu/libngspice.so
> $ dpkg -S /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0
>> libngspice0:amd64: /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0

What about libngspice.so.0 symlink? Which package ships that? Anyway, it
makes sense to request a particular version of the library in case the
API changes in the future.

> So looking manually at the binaries build from the kicad source by ldd I
> can see a lot linked libraries but no library libngspice.so.0! Seems the
> library is simply opened by dlopen. So that's the reason why the
> packaging isn't adding a dependency on the package libngspice0.

You are correct. The library used to be linked with eeschema, but we
have faced problems that could be resolved only by reloading the
library. I am afraid it has to stay this way for the time being.

Regards,
Orson

> [1] https:/bugs.debian.org/911965
> 



signature.asc
Description: OpenPGP digital signature
___
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

[Kicad-developers] Separated debug symbols

[Maciej Suminski]

What do you think about providing archives with debug symbols for
Windows builds? It is a platform where we rarely get a stacktrace,
because the process is not trivial and Windows debug builds take lots of
space (_pcbnew.kiface is ~1.5 GB on my PC). Normally it would be wasted
bandwidth, but from time to time we get bug reports which noone else can
reproduce and then a stacktrace would be of great help.

I have written a patch that adds a CMake flag to split debug information
to another file. This way we could offer compact binaries to the users
and ask them to download debug information only in case of serious
problems. There is already GDB shipped with the nightly installers, so
then getting a stacktrace becomes feasible or we could use catchsegv [1]
for an automated approach (see the attached example log; do not worry
about the null pointer dereference - I added it temporarily to test the
software). Obviously, Thomas' crash reporter looks even more convenient,
but it is not mingw-gcc compatible [2]. The patch is also compatible
with BUILD_SMALL_DEBUG_FILES flag.

I have not pushed the patch yet, as I still wonder whether adding
another CMake flag is a good idea. Just now I realized that there are
just a few extra commands to create the needed files, so perhaps they
could be executed by the build scripts on Jenkins hosts.

Cheers,
Orson

1. https://github.com/jrfonseca/drmingw/tree/master/src/catchsegv
2.
https://docs.wxwidgets.org/3.0/group__group__funcmacro__appinitterm.html#ga28a4fb827b93fa6bac18c9666c23ee10
From 6d7f070ed838f70a739406dae24640c6831bd0b8 Mon Sep 17 00:00:00 2001
From: Maciej Suminski 
Date: Thu, 25 Oct 2018 20:51:32 +0200
Subject: [PATCH] Added KICAD_SPLIT_DEBUG CMake flag to store debug symbols as
 a separate file

---
 CMakeLists.txt   | 12 
 CMakeModules/SplitDebug.cmake| 29 +
 cvpcb/CMakeLists.txt |  4 
 eeschema/CMakeLists.txt  |  5 +
 gerbview/CMakeLists.txt  |  5 +
 pagelayout_editor/CMakeLists.txt |  5 +
 pcb_calculator/CMakeLists.txt|  5 +
 pcbnew/CMakeLists.txt|  5 +
 8 files changed, 70 insertions(+)
 create mode 100644 CMakeModules/SplitDebug.cmake

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 246277826..8e646488e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -98,6 +98,10 @@ option( KICAD_INSTALL_DEMOS
 "Install KiCad demos and examples (default ON)"
 ON )
 
+option( KICAD_SPLIT_DEBUG
+"Saves debugging data to a separate file (default OFF)"
+OFF )
+
 # when option KICAD_SCRIPTING OR KICAD_SCRIPTING_MODULES is enabled:
 # PYTHON_EXECUTABLE can be defined when invoking cmake
 # ( use -DPYTHON_EXECUTABLE=/python.exe or python2 )
@@ -116,6 +120,14 @@ if ( KICAD_SCRIPTING_ACTION_MENU AND NOT KICAD_SCRIPTING )
 set ( KICAD_SCRIPTING ON )
 endif()
 
+if( KICAD_SPLIT_DEBUG )
+if( NOT CMAKE_BUILD_TYPE STREQUAL "Debug" )
+message( WARNING "KICAD_SPLIT_DEBUG makes sense only for debug builds" )
+endif()
+
+include( SplitDebug )
+endif()
+
 option( BUILD_GITHUB_PLUGIN "Build the GITHUB_PLUGIN for pcbnew." ON )
 
 option( KICAD_SPICE "Build KiCad with internal Spice simulator." ON )
diff --git a/CMakeModules/SplitDebug.cmake b/CMakeModules/SplitDebug.cmake
new file mode 100644
index 0..f85fed301
--- /dev/null
+++ b/CMakeModules/SplitDebug.cmake
@@ -0,0 +1,29 @@
+# Copyright (C) 2018 CERN
+# @author Maciej Suminski 
+#
+# This program is free software: you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by the
+# Free Software Foundation, either version 3 of the License, or (at your
+# option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program.  If not, see .
+
+# SplitDebug separates debug information to another file,
+# leaving the original binary stripped and compact.
+
+function( SplitDebug target filename )
+add_custom_command( TARGET ${target} POST_BUILD
+COMMAND objcopy --only-keep-debug ${filename} ${filename}.debug
+COMMAND strip --strip-debug --strip-unneeded ${filename}
+# TODO objcopy can also take --strip-debug
+COMMAND objcopy --add-gnu-debuglink="${filename}.debug" ${filename}
+COMMENT "Creating a debug info file for ${filename}"
+# OUTPUT ${filename}.debug
+)
+endfunction()
diff --git a/cvpcb/CMakeLists.txt b/cvpcb/CMakeLists.txt
index eb77f6b68..9c7b55509 100644
--- a/cvpcb/CMakeLists.txt
+++ b/cvpcb/CMakeLists.txt
@@ -193,6 +193,10 @@ if( MAKE_LINK_MAPS )
 LINK_FLAGS "${TO_LINKER},-cref ${TO_LINKER},-Map=_cvpcb.kiface.map" )
 

[Kicad-developers] eeschema depends on libngspice.so instead of libngspice.so.0?

[Carsten Schoenert]

Hi,

I got a bug report [1] for KiCad in Debian testing/unstable because of a
not working ngspice based simulation in eeschema.

I was first searching for the reason why the packaging isn't detecting
that the assumed library libngspice.so.0.0.0 was detected as a dependency.
The bugreporter stated that he is needed the package libnsgpice0-dev to
get eeschema working with simulation. So I tried around this information
and the reporter is right. If I start eeschema without this package
installed I get an error message that libngspice.so was not found.

This is an error in my eyes because eeschema is not looking for the
needed library with the API version it's build against. As libngspice is
using a API version 0 the correct library to look for would be
libngspice.so.0 and not libngspice.so that is normally a symlink to the
most recent version of the library and only used while linking.
Thus we ship -dev packages in Debian with a symlink of a file libfoo.so
to full versioned named library. For libngspice0 this looks like this:

> $ ls -l /usr/lib/x86_64-linux-gnu/libngspice.so*
> lrwxrwxrwx 1 root root  19 Okt 15 19:50 
> /usr/lib/x86_64-linux-gnu/libngspice.so -> libngspice.so.0.0.0
> lrwxrwxrwx 1 root root  19 Okt 15 19:50 
> /usr/lib/x86_64-linux-gnu/libngspice.so.0 -> libngspice.so.0.0.0
> -rw-r--r-- 1 root root 7091024 Okt 15 19:50 
> /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0

> $ dpkg -S /usr/lib/x86_64-linux-gnu/libngspice.so
> libngspice0-dev:amd64: /usr/lib/x86_64-linux-gnu/libngspice.so
$ dpkg -S /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0
> libngspice0:amd64: /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0

So looking manually at the binaries build from the kicad source by ldd I
can see a lot linked libraries but no library libngspice.so.0! Seems the
library is simply opened by dlopen. So that's the reason why the
packaging isn't adding a dependency on the package libngspice0.

[1] https:/bugs.debian.org/911965

-- 
Regards
Carsten Schoenert

___
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] [PATCH] Print stacktrace when SIGSEGV or SIGABRT appears

[Wayne Stambaugh]

On 10/26/2018 02:39 AM, Maciej Sumiński wrote:
> On 10/26/18 2:29 AM, Tomasz Wlostowski wrote:
> [snip]
>> I made a variant of the dialog that (hopefully) is easier to understand.
>> This raises another question: do we have any means of reporting bugs
>> without forcing the users to register on launchpad, for example a public
>> Kicad bug email (e.g. b...@kicad-pcb.org?). @Wayne, what do you think
>> about such solution?

I'm OK with this.  I don't know how helpful it will be but we can try it
and see if we get some useful bug reports.

> 
> I think this might be easily arranged via https requests and KiCad
> Janitor help. The only thing I am afraid of is potential spam we are
> going to receive, but then we can simply shut down the service.

Sounds like a plan.  We can go this route and always shut it down if
it's not working as expected.

> 
> Cheers,
> Orson
> 
> 
> 
> ___
> 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
> 



signature.asc
Description: OpenPGP digital signature
___
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] [PATCH] Print stacktrace when SIGSEGV or SIGABRT appears

[Maciej Sumiński]

On 10/26/18 2:29 AM, Tomasz Wlostowski wrote:
[snip]
> I made a variant of the dialog that (hopefully) is easier to understand.
> This raises another question: do we have any means of reporting bugs
> without forcing the users to register on launchpad, for example a public
> Kicad bug email (e.g. b...@kicad-pcb.org?). @Wayne, what do you think
> about such solution?

I think this might be easily arranged via https requests and KiCad
Janitor help. The only thing I am afraid of is potential spam we are
going to receive, but then we can simply shut down the service.

Cheers,
Orson



signature.asc
Description: OpenPGP digital signature
___
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