Thanks for this information. It should be a good idea to write about the reasons for using a own libcontext implementation and the problems with the existing Boost versions at least on kicad-pcb.o and finally some there in the release notes of KiCad 5 to prevent future questions about this all.
One outcome of the Boost development was definitely the speed up of future C++ standards. It's some years ago I've followed this all more active. Now there is C++17 alive for some time and the evolving hasn't stop and people working on C++20. I hope one day the problems you have can be solved by using standard functions of an ISO/IEC standard.
I will modify the build rules for future KiCad uploads to the Debian build infrastructure so the buildd's will only take care for arm64, i386, amd64 and armhf (armvt6 or armvt7).
@Tom
Thanks for this information. It should be a good idea to write about the reasons for using a own libcontext implementation and the problems with the existing Boost versions at least on kicad-pcb.o and finally some there in the release notes of KiCad 5 to prevent future questions about this all.
One outcome of the Boost development was definitely the speed up of future C++ standards. It's some years ago I've followed this all more active. Now there is C++17 alive for some time and the evolving hasn't stop and people working on C++20. I hope one day the problems you have can be solved by using standard functions of an ISO/IEC standard.
I will modify the build rules for future KiCad uploads to the Debian build infrastructure so the buildd's will only take care for arm64, i386, amd64 and armhf (armvt6 or armvt7).