Coin/Pivy issue on Py3 / Qt5 build

[kkremitzki]

At the moment, I can't get the docker image to pick up the environment variables. Will maybe give an Ubuntu VM a try, since it works for NormandC.

If you want a working Python 3 package you could always make a Debian Unstable VM which has the libexpat problem fixed as well. The process is basically just grabbing a Debian Testing ISO, installing it on a VM, and then editing /etc/apt/sources.list as outlined here: https://www.freecadweb.org/wiki/DebianUnstable

[Joel_graff]

If you want a working Python 3 package you could always make a Debian Unstable VM which has the libexpat problem fixed as well.... [

I'm afraid I'm out of ideas...

Just a final note on this point, I did a fresh install of Linux Mint 19.1. added the FreeCAD-daily ppa and ran build-dep. Then followed NormandC's instructions on building FreeCAD.

At first, it told me it couldn't import QtCore. Fixed that with:

Code: Select all

sudo apt install python3-pyside2.qtcore

Then I ran FreeCAD again and was left with the 81-element stack trace resulting from the segfault I quoted on page 1.

Then, on a whim, I renamed my .FreeCAD folder... and it starts perfectly - no crash when I try to import lxml.

So.. ummm.. nevermind.

Going to see if I can track down the offending module code, though...

[Joel_graff]

Looks like the problem is in microelly's geodata wb.

Specifically:

Code: Select all

import cv2

If I try to import it in the FreeCAD python console, the same crash occurs. I'm guessing it's another library binary incompatibility issue as it imports without issue in the Python3 console.

Since it's related to the OpenCV module, I checked to see if I had python3-opencv installed. It was missing, so I fixed that. No effect, unfortunately.

[David_D]

At the moment, I can't get the docker image to pick up the environment variables. Will maybe give an Ubuntu VM a try, since it works for NormandC.

I have recently fixed a few issues with the docker image. If you pull it again, your issue may have been fixed. Failing that, if you explain what env vars you're having difficulty with, I might be able to help.

[Joel_graff]

I have recently fixed a few issues with the docker image. If you pull it again, your issue may have been fixed. Failing that, if you explain what env vars you're having difficulty with, I might be able to help.

I was trying to work past compilation issues, which I'm slowly sorting out. In any case, I don't use docker at all, so when I tried it, I could have been doing something wrong. The issue I had was getting it to pick up on the source / build environment variables. I defined the vars, exported them before running the image, and even defined them in the commandline when running the image and it still defaulted to the /mnt values.

[David_D]

I have recently fixed a few issues with the docker image. If you pull it again, your issue may have been fixed. Failing that, if you explain what env vars you're having difficulty with, I might be able to help.

I was trying to work past compilation issues, which I'm slowly sorting out. In any case, I don't use docker at all, so when I tried it, I could have been doing something wrong. The issue I had was getting it to pick up on the source / build environment variables. I defined the vars, exported them before running the image, and even defined them in the commandline when running the image and it still defaulted to the /mnt values.

Ah, so a few things to keep in mind there, that may be the cause of your issue.

First, env vars defined on the host machine are not carried over into the docker container (Unless you explicitly make them). You have to define them from within the docker container. I'd be interested to hear what they are, and why you want to use them.

Second, assuming you're using the build bash script included with the docker image:

Code: Select all

/root/build_script.sh

, you may have better luck explicitly passing the env vars as flags there, because the env vars you're using may be overwritten by an explicit flag within the build script.

[Joel_graff]

First, env vars defined on the host machine are not carried over into the docker container (Unless you explicitly make them). You have to define them from within the docker container. I'd be interested to hear what they are, and why you want to use them.

Second, assuming you're using the build bash script included with the docker image:

I'm referring to the fc_build / fc_source variable definitions laid out in the readme file on your gitlab repo under the 'run image' section.

It indicated fc_source and fc_build needed to be defined before running the image, then it appears they're also defined in the commandline switches when loading the image - which seemed redundant to me. Nevertheless I did both, providing the same values in both cases...

Having never used docker, I'm sure there's something I didn't understand.

[David_D]

I'm referring to the fc_build / fc_source variable definitions laid out in the readme file on your gitlab repo under the 'run image' section.

It indicated fc_source and fc_build needed to be defined before running the image, then it appears they're also defined in the commandline switches when loading the image - which seemed redundant to me. Nevertheless I did both, providing the same values in both cases...

Having never used docker, I'm sure there's something I didn't understand.

Ah, I see. There's a small misunderstanding. See relevant docs here. The variables are not getting defined a second time. The second value after the semicolon in:

Code: Select all

-v $fc_source:/mnt/source

is not the variable getting defined a second time. Rather the value before the colon is where to make the mount on the host machine, and the value after the colon is where to make the mount on the docker container.

You can tell this is the case, because with bash, an environment variable prefixed with a dollar sign causes the value of the environment variable to be substituted in. As an example, this:

Code: Select all

fc_source=/home/my_name/code/freecad_source
echo "$fc_source:/mnt/source"

is exactly the same as doing this:

Code: Select all

echo "/home/my_name/code/freecad_source:/mnt/source"

And you can test that in your terminal.

To use the environment variables as intended, assign fc_source and fc_build to the locations of your source directory and your build directories on your host machine, and don't worry about where they'll end up on the docker container. The build script will find them in the correct location.

[microelly2]

Looks like the problem is in microelly's geodata wb.

Specifically:

Code: Select all

import cv2

If I try to import it in the FreeCAD python console, the same crash occurs. I'm guessing it's another library binary incompatibility issue as it imports without issue in the Python3 console.

Since it's related to the OpenCV module, I checked to see if I had python3-opencv installed. It was missing, so I fixed that. No effect, unfortunately.

I put it on my task list to test with the new CV3/CV4.