Boost Lib Problem on 64 Bit machines != Linux?

Im running some “kicad-devel” port Versions of KiCad on FreeBSD and since I updated my Os from 10-stable to 11-stable I have problems with a crashing pcbnew. The crashes are related to this:


"Boost 1.59

On 64-bit Windows, KiCad’s usage of the boost context library is currently broken due to changes in the library. This causes pcbnew to crash on start. The only workaround is to use boost 1.56 or 1.57 which are known to work."

The most parts of my desktop programs that using boost-libs are needing Version 1.6.3 and I’ve “patched in” an old boost-lib version to just let KiCad run. So far as I know OS-X has the same Problem.

Could please someone address this problem and move pcbnews library interface to an actual state?
Currently it is almost impossible to run KiCad on FreeBSD w/o fiddeling for hours to move around that, so please, please …

Regards,

Holm

boost::context is an absolute freaking mess.

We just replaced it. Less than 45 minutes ago. Try a new build and see if it works properly with the new standalone libcontext.

1 Like

Ok, thanks, I’ll try and report back…

Regards

Holm

…hhm…problems over problems.

First I got unresolved dynamic linking errors regarding jump_fcontext and make_fcontext while starting _pcbnew.kiface.
It seems that libcontext.cpp is providing _jump_fcontext() and pcbnew.kiface wants jump_fcontext.
Next I’ve hacked away some underscores from libcontext.cpp…and then i get thinks like this:

— gerbview/CMakeFiles/gerbview_kiface.dir/all —
/usr/bin/make -f gerbview/CMakeFiles/gerbview_kiface.dir/build.make gerbview/CMakeFiles/gerbview_kiface.dir/build
— pagelayout_editor/CMakeFiles/pl_editor_kiface.dir/all —
/usr/bin/ld: …/common/libcommon.a(libcontext.cpp.o): relocation R_X86_64_PC32 against `__exit’ can not be used when making a shared object; recompile with
-fPIC
/usr/bin/ld: final link failed: Bad value
c++: error: linker command failed with exit code 1 (use -v to see invocation)
— gerbview/CMakeFiles/gerbview_kiface.dir/all —
— gerbview/CMakeFiles/gerbview_kiface.dir/onleftclick.cpp.o —
— pagelayout_editor/CMakeFiles/pl_editor_kiface.dir/all —
*** [pagelayout_editor/_pl_editor.kiface] Error code 1

…thats a little out of my bounds…and has something todo with clang+x86_64 and dynamic linking.

:frowning:

Regards,

Holm

You might want to file a bug report on this. FreeBSD is officially unsupported, so don’t expect anything fast, but it’s definitely something I’d take a look at.

If not for this breakage, is it otherwise straightforward to build KiCad on FreeBSD? If not you should probably reference some sort of build guide in the report.

Feel free to assign me to the report (real name Chris Pavlina) to remind me to take a look at it, and possibly deflect a bit of “go away we don’t support BSD” :wink:

Hmm, yes Chris, I’m in the contact with Michael, the usual maintainer of the KiCad port to FreeBSD and there is an other friend (Joerg) I want to talk to about this.
I think half of the problems are clang related. Clang it isn’t gcc which it want’s to emulate.
I’ve build KiCad from sources more than one time in the past, but not really by myself since FreeBSD10 I think, I’ve used and modified Michaels port for that.
I have only very small experience with dynamic loading and inline assembler, especially on x86_64 and I don’t know where the differences or pitfalls are. It was never so “straightforward” to build KiCad on FreeBSD but it was possible with some corrections here and there…I’m sure we get that problem sorted. I’m an electronican with some unix experiences, I’m able to write programs ans compile them, bit this is really a bit difficult since the entire build environment isn’t that easy to understand…

Is that really working on apple 64 bit? Should be most similar to FreeBSD I think ant that is was Michels Patches assuming…

I don’t have problems with “go away we don’t support BSD” … I have an head made from iron-wood :slight_smile:
I think support or not is mostly a question of manpower…

Regards,

Holm

I

Yeah, it works fine on Apple 64-bit (I test there quite regularly), as well as clang on Linux 64-bit, so it’s not just a clang issue (though perhaps clang is involved).

Interesting that it’s complaining about libcontext not being complied -fPIC – it really should be, and if it isn’t then I’m stunned it works at all. I would definitely recommend filing a bug report, perhaps tag the report “cern” to bring it to the attention of the CERN devs (one of whom maintains libcontext), and make sure to include the bit warning about -fPIC.

I’m wary of the underscore-removing though as that’s not necessary anywhere else. Make sure to mention that in the report too, or just link to this thread.

libcontext is in fact compiled with -fPIC, I’ve verified that.
Before I’m filing a Bug report I want update my build system to the last stable OS version first. I don’t want to generate bug reports it’s my own fault that triggers the bugs.

The machine is updating the OS sources now, it will take some time. I think I can tell more tomorrow.

Regards,

Holm

Ok, here I’m again…with good news:

there is no need to make a bug report :slight_smile:

The problem was simple to select the proper set of calling conventions in libcontext.h and I’m patched that to use the linux 86_64 definitions which seems to fit better then the apple ones. I have KiCAD now running on two FreeBSD 11-stable machines, Git Versions from yesterday and today …looks good so far.

Regards,

Holm

…forgot this: Chris you asked how much effort it is to build KiCad on FreeBSD:

currently I’m using Michael Reifenberger’s Port (see FreeBSD Ports system) to pull the files from github, setting up the environment and install the system on the computer. For Building KiCad there are currently 3 small patches neccessary where the first one isn’t really a FreeBSD related patch…

patch-include-kiway.h
--- include/kiway.h.orig        2015-01-10 18:11:39.000000000 +0000
+++ include/kiway.h     2015-01-11 10:51:52.458174797 +0000
@@ -115,5 +115,5 @@
 #define KIFACE_INSTANCE_NAME_AND_VERSION   "KIFACE_1"
 
-#if defined(__linux__) || defined(__FreeBSD__)
+#if defined(__linux__) || defined(__FreeBSD__) || defined(__DragonFly__)
  #define LIB_ENV_VAR    wxT( "LD_LIBRARY_PATH" )
 #elif defined(__WXMAC__)
patch-include-gal-graphics_abstraction_layer.h
--- include/gal/graphics_abstraction_layer.h.orig       2016-04-16 13:14:32.003824016 +0200
+++ include/gal/graphics_abstraction_layer.h    2016-04-16 13:15:06.143789160 +0200
@@ -31,4 +31,5 @@
 #include <stack>
 #include <limits>
+#include <cmath>

#include <math/matrix3x3.h>


patch-include-system-libcontext.h

--- include/system/libcontext.h.orig    2017-03-13 11:47:23.495919000 +0100
+++ include/system/libcontext.h 2017-03-13 11:51:12.678651000 +0100
@@ -23,13 +23,15 @@
 
 
-#if defined(__GNUC__) || defined(__APPLE__)
+#if defined(__GNUC__) || defined(__APPLE__) || defined(__FreeBSD__)
 
     #define LIBCONTEXT_COMPILER_gcc
 
-    #if defined(__linux__)
+    #if defined(__linux__) || defined(__FreeBSD__)
        #ifdef __x86_64__
            #define LIBCONTEXT_PLATFORM_linux_x86_64
            #define LIBCONTEXT_CALL_CONVENTION
-
+       #elif __amd64
+           #define LIBCONTEXT_PLATFORM_linux_x86_64
+           #define LIBCONTEXT_CALL_CONVENTION
        #elif __i386__
            #define LIBCONTEXT_PLATFORM_linux_i386

that’s all so far.

Regards,
Holm

1 Like

Testing this on FreeBSD has kinda slipped onto my back burner, but I’m going to check if there’d be any objection to merging these changes.

:slight_smile:
Regards,

Holm