Le 04/04/2014 15:04, Dick Hollenbeck a écrit : > I'm sure you are not submitting this for a potential commit, right? Clearly the objectif of this patch is NOT to be commit. > Because: > > 1) The comment is below the line of text that it refers to. Yes it's a paste an copy from a solution I found on the link: http://bugs.python.org/issue19153 > 2) The comment is bullshit, boost is not part of the discussion. The comment > should read > something like, "I don't know why this works, but is solves bug number ???. > It's temporary." Yes I forgot to remove the comment when I copy... And of course it's temporary to check If the workarround has effect... I have try to find a solution by trace the library loading: LD_DEBUG=all pcbnew But the issue look to be due to a compilation option on some ubuntu libs. Anyway I'm NOT sure of that... > 3) You are adding python to 7 programs, only one of which is uses python. Of course, I repeat this is NOT a patch to commit but a patch to check if the issue is the same I found... > 4) You are adding python to all operating systems, with no evidence that the > problem > extends beyond linux. Same answer ;) > 5) You are adding python to all build, even if python is not used at all, > like my builds. Same answer... > It's basically stupid, without explanation, and no effort was to understand > the problem. > Its like taking medicine from your Grandmother's medicine cabinet without > knowing what it > does. It might have embarrassing consequences. As I explain before, it was to identify the issue. If it's fix for others users, my idea was to apply this work arround ONLY for the ppa building (if I keep the KICAD_SCRIPTING_WXPYTHON option activated). > I don't think it should be committed. I had no idea that wxPython scripting > was already > so important and widely used. On my ppa It's activated. One of the workarround I propose was to DISABLE "KICAD_SCRIPTING_WXPYTHON" on ppa. This is the purpose of my first email...
> I think somebody needs to prepare a debugging version of python and single > step into the > DSO, the call stack at the point of crash passes through > wxPyBeginBlockThreads(), and that > is the first thing in the libpython.so that is called when called from > _pcbnew.kiface. > That's what I intend to do, when I get to it. Yes it could be great but, as I see some, other software have this issue on some Linux distribution. I'm NOT sure of that, but as I understand the issue is ouside kicad... Regards _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
