Created attachment 242650 [details] Update to 7.0.5 - Update to 7.0.5
Did you actually test-run that? Over here, I end up with a dysfunctional kicad (e.g. eeschema doesn't start). (I tried the simple approach like you between 7.0.3 and 7.0.5, but it's a mess and ENOTENOUGHTIME)
Hey guys, do we have any news on this?
Upstream 7.0.6 was released yesterday.
I spent about a gazillion evenings working - I think I'm getting close. After hours of debugging the KiCAD code I figured out that this has something to do with loading configs. If one removes ~/.config/kicad/7.0 everything works as expected. However, this leads to the creation of a new ~/.config/kicad/7.0 and subsequent launches of KiCAD will again result in both eeeschema and pcbnew crashing immediately again. I observe two things when that happens: - SETTINGS_MANAGER::GetAppSettings() get called before registration - The call to KIWAY::KiFACE() inside of KIWAY::Player() is returning nullptr and there is no check for that prior to dereferencing the pointer. I don't know yet whether KIWAY::KiFACE() returning nullptr is related to the settings issue. I'm also not yet sure what the underlying cause is especially given the fact that nobody in the Windows/Linux/MacOS world appears to have such problems. Note: I'm currently doing this on upstream 7.0.6 with the hopes of being able to provide a port patch for that more recent upstream release.
(In reply to Joel Bodenmann from comment #4) The actual problem ist that kicad uses dynamic_cast for downcasting across translation units and shared objects (a lot of kicad's code is loaded dynamically). That is a "generally bad idea" on clang/libc++ platforms (as ours) but "kinda works most times" on gcc/libstdc++ platforms (as almost all Linuxen are) (I have no idea what the msvc folks do, and I also can't say anything about the OSX platform and their toolchain). The problem started when kicad "optimized" some things - including the settings manager - in 7.0.3 (we had earlier fallout from that in other places, where it was workaroundable, but those workarounds are not feasible in the settings manager), and it hasn't changed up to and including 7.0.7 (which is to say, forget about 7.0.6, unless you want to learn about the "implementation dependent" parts of the C++ runtime and ELF binary format).
(In reply to Christoph Moench-Tegeder from comment #5) dynamic_cast based down casting across TUs should not be a problem. Across different shared objects that's a different story tho. > forget about 7.0.6, unless you want to learn about the "implementation dependent" parts of the C++ runtime and ELF binary format). Incidentally, I already did that :D I had to deal with this exact scenario in the past. GCC "just worked" and clang did build correctly but (rightfully?) couldn't perform the dynamic_cast across shared object boundaries. As it turned out, clang has a linker flag for that (--export-dynamic if I recall correctly) which leads to the same behavior as what GCC does (but don't quote me on that). If that is a suitable workaround/fix to make 7.0.6 work on FreeBSD I'd be all for it. I'll gladly give that a try tonight. Your comment sounds like you know that this situation is different in 7.0.7 tho?
(In reply to Joel Bodenmann from comment #6) > As it turned out, clang has a linker flag for that (--export-dynamic if I recall correctly) which leads to the same behavior as what GCC does (but don't quote me on that). That's the flag, but it's not sufficient here: if you look closely, you can see that kicad includes and linkss stuff all over the place, and as I've been told, that totally breaks the One Definition Rule (after re-reading that, that's correct; and violating that rule is just "undefined behaviour" and the compiler is not required to tell you about that) and there's no flag for that. If you look even closer, you can see that you got typeinfos for KICAD_SETTINGS and friends in all shared objects, but at different addresses. And if you look even more closely, you can see that even the typeinfo().hash_code() of the "same" type changes depending on where you are in the code. It looks like the sloppy C++-coding (sorry not sorry) finally came calling, and fixing that will somewhat break the scope of a patch (I'd call that re-architecting or refactoring). >Your comment sounds like you know that this situation is different in 7.0.7 tho? No. it's the same. It's just that 7.0.6 is basically obsolete by now.
(In reply to Christoph Moench-Tegeder from comment #7) I was pretty much just about to post here that the entire thing seems like a complete clusterfuck when you replied. > fixing that will somewhat break the scope of a patch (I'd call that re-architecting or refactoring). I agree. I have no idea what we can do at this point to keep KiCAD working on FreeBSD. Do you have any idea whether upstream is aware of this "issue"?
Upstream does seem to build on MacOS using clang: https://dev-docs.kicad.org/en/build/macos/
(In reply to Joel Bodenmann from comment #8) We are aware, the code base is a clusterfuck and it's a huge task to fix. It's the result of 2 decades of code piling up. Does it not work with -flat_namespace added? It should clean up linker segregating copies of object by module library name which is specific to clang but not gcc or MSVC. But yes, macOS builds use clang just fine. BSD-land is changing something.
> cad/kicad: Update to 7.0.5 … to 7.0.8? (Update the summary line?) Not wishing to complicate things, for anyone. Just curious. <https://gitlab.com/kicad/code/kicad/-/tags> <https://www.freshports.org/cad/kicad/>
(In reply to Mark R from comment #10) -flat_namespace also fails. I tried using GCC(12) instead, but it fails compilation then: --- thirdparty/clipper/CMakeFiles/clipper.dir/all --- In file included from /usr/include/c++/v1/__functional_base:23, from /usr/include/c++/v1/concepts:134, from /usr/include/c++/v1/__iterator/incrementable_traits.h:14, from /usr/include/c++/v1/__iterator/iterator_traits.h:14, from /usr/include/c++/v1/__algorithm/search.h:15, from /usr/include/c++/v1/functional:490, from /junk/FreeBSD/ports/cad/kicad/work/kicad-7.0.8/thirdparty/clipper/clipper.hpp:52, from /junk/FreeBSD/ports/cad/kicad/work/kicad-7.0.8/thirdparty/clipper/clipper.cpp:41: In function 'void* std::__1::__libcpp_operator_new(_Args ...) [with _Args = {long unsigned int}]', inlined from 'void* std::__1::__libcpp_allocate(size_t, size_t)' at /usr/include/c++/v1/new:261:31, inlined from '_Tp* std::__1::allocator<_Tp>::allocate(size_t) [with _Tp = ClipperLib::IntPoint]' at /usr/include/c++/v1/__memory/allocator.h:108:62, inlined from 'static std::__1::allocator_traits<_Alloc>::pointer std::__1::allocator_traits<_Alloc>::allocate(allocator_type&, size_type) [with _Alloc = std::__1::allocator<ClipperLib::IntPoint>]' at /usr/include/c++/v1/__memory/allocator_traits.h:262:28, inlined from 'void std::__1::vector<_Tp, _Alloc>::__vallocate(size_type) [with _Tp = ClipperLib::IntPoint; _Allocator = std::__1::allocator<ClipperLib::IntPoint>]' at /usr/include/c++/v1/vector:1015:61, inlined from 'typename std::__1::enable_if<(std::__1::__is_cpp17_forward_iterator<_InputIter>::value && std::__1::is_constructible<_Tp, typename std::__1::iterator_traits<_ForwardIterator2>::reference>::value)>::type std::__1::vector<_Tp, _Alloc>::assign(_ForwardIterator, _ForwardIterator) [with _ForwardIterator = ClipperLib::IntPoint*; _Tp = ClipperLib::IntPoint; _Allocator = std::__1::allocator<ClipperLib::IntPoint>]' at /usr/include/c++/v1/vector:1482:20: /usr/include/c++/v1/new:237:24: warning: argument 1 value '18446744073709551600' exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] 237 | return ::operator new(__args...); | ~~~~~~~~~~~~~~^~~~~~~~~~~ /usr/include/c++/v1/new: In member function 'typename std::__1::enable_if<(std::__1::__is_cpp17_forward_iterator<_InputIter>::value && std::__1::is_constructible<_Tp, typename std::__1::iterator_traits<_ForwardIterator2>::reference>::value)>::type std::__1::vector<_Tp, _Alloc>::assign(_ForwardIterator, _ForwardIterator) [with _ForwardIterator = ClipperLib::IntPoint*; _Tp = ClipperLib::IntPoint; _Allocator = std::__1::allocator<ClipperLib::IntPoint>]': /usr/include/c++/v1/new:180:66: note: in a call to allocation function 'void* operator new(size_t)' declared here 180 | _LIBCPP_NODISCARD_AFTER_CXX17 _LIBCPP_OVERRIDABLE_FUNC_VIS void* operator new(std::size_t __sz) _THROW_BAD_ALLOC; | ^~~~~~~~ --- thirdparty/clipper2/CMakeFiles/clipper2.dir/all --- cc1plus: all warnings being treated as errors
(In reply to Mark R from comment #10) Where can I find the actual command invocation that is used to build the MacOS release? The CI directory for MacOS contains just a README.md file only.
(In reply to Joerg Wunsch from comment #13) We don't run CI on macOS. Instead we have this beast to deal with what can be summed up as "Apple hates anything that isn't swift these days" https://gitlab.com/kicad/packaging/kicad-mac-builder Otherwise we do have compiler flags and such stashed in the main CMakeList https://gitlab.com/kicad/code/kicad/-/blob/master/CMakeLists.txt#L366
(In reply to Mark R from comment #10) Mark, I tried to link everything with -flat_namespace but still no luck. I'm currently working with the 7.0.9 branch which builds out-of-the-box without any of the patches that are currently shipping with the 7.0.2 FreeBSD port. After building, KiCAD starts but trying to open either eeschema or pcbnew is throwing an error in common/kiway.cpp:280: 02:51:04: Failed to load shared library '/home/jbo/projects/kicad/cmake-build-debug/kicad/_pcbnew.kiface': Cannot open "/home/jbo/projects/kicad/cmake-build-debug/kicad/_pcbnew.kiface" 02:51:04: IO_ERROR: Failed to load kiface library '/home/jbo/projects/kicad/cmake-build-debug/kicad/_pcbnew.kiface'. from kiway.cpp : KiFACE() line 280 02:51:04: Error loading editor. 02:51:04: Application failed to load. Do you have any other ideas, pointers or wild guesses what we can do to get KiCAD up and running under FreeBSD again?
(In reply to Joel Bodenmann from comment #15) >After building, KiCAD starts but trying to open either eeschema or pcbnew is throwing an error in common/kiway.cpp:280: Is the path correct for pcbnew's kiface there? Running kicad from the build directory requires a special env var KICAD_RUN_FROM_BUILD_DIR at launch time. Otherwise you have to make install and run it.
(In reply to Mark R from comment #16) Actually yea, you don't have the correct env var. >'/home/jbo/projects/kicad/cmake-build-debug/kicad/_pcbnew.kiface'. should really be '/home/jbo/projects/kicad/cmake-build-debug/pcbnew/_pcbnew.kiface'. which it will be once you set the env var
Hi, I'm getting Unhandled exception class: St13runtime_error what: Tried to GetAppSettings before registering too on the -devel branch after updating from newer sources. Seems we are stuck currently...
Is there any hope that this get fixed in the more or less future upstream, or have I to use Linux next time? Regards, Holm
(In reply to holm from comment #19) Well, the fix upstream is a big refactor to unfuck our static library abuse that's been started but...it could be another year or two before it's complete between all the other things we do.
1 or 2 years? Doesn't sound nice. In my ears this sounds like "use Linux or Windows if you couldn't be happy with wine or an VM using Windowsor if you want to just get your work done". What are all the other things you do if not getting applications to work and who needs that? Sorry for the sarcasm.. but it feels that every half year there is another thing that just doesn't work anymore on FreeBSD but compiling and installing LLVM in different versions seems to be the new killer application for FreeBSD. Regards, Holm
Changes were made to the upstream master that will probably allow running on freebsd as a side effect. This will not be backported to 8.0