[Bug 211641] graphics/py-mayavi mayavi2 runtime error

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211641

--- Comment #13 from vladimir.chukharev at gmail.com ---
(In reply to Kubilay Kocak from comment #10)
That's right, I consider setting env as a temporary workaround in a hope that
the core problem will be solved in the compiling infrastructure relatively
soon. That's why I did not put much effort into cleaning the patch (in this
part).

Unfortunately, the patch from bag 208120 does not solve it on my computer.

Now to your comments.
> * Use PYTHONPREFIX_SITELIBDIR for ${STAGEDIR}${PREFIX}/lib/python2.7/site-packages/tvtk/array_ext.so

Thanks, I'll make this change. Now testing.

> * The post-install -> post-stage switch is unexplained (for stripping). post-install should be fine for both commands executed

Yes, they are both fine. If I understand correctly, stripping before packaging
is slightly better. Even better, before staging, e.g. in post-build:, but then
it cannot be coupled with patching bin/mayavi2 script which is created only in
stage.

> * The additional of mayavi2 executable is unexplained. Related, for version suffixed script names, USE_PYTHON=concurrent is preferred.

Actually, this is just adding 'import os; os.environ["LD_LIBRARY_PATH"] =
"/usr/local/lib/gcc48"' with proper formatting to the existing script by
overwriting the script with a modified one. This is the very workaround. In the
previous patch, I tried to rename the original script and call it from a shell
wrapper, but did not manage to add the renamed script into the auto generated
plist.
As to suffixes, some of the used libraries are not yet python3 ready.

>* os.environ["LD_LIBRARY_PATH"] = "/usr/local/lib/gcc48" should likely use %%LOCALBASE%% in files, and be replaced (REINPLACE_CMD) in post-patch to to be prefix safe. You'll probably need SUB_FILES too.

The unknown part of this is how to find out the version of gcc in the
Makefile... Can you help with it, please?

> Finally please reconfirm QA across as many arch/versions as possible, as this will be committed then merged to the quarterly branch.

My notebook is about 6 years old and has 4GB of memory. Adding the second jail
to poudriere took more than 24 hours. So, I cannot promise testing on anything
more than 10-STABLE and 9-STABLE on amd64. Sorry.

-- 
You are receiving this mail because:
You are the assignee for the bug.