I'm having a lot of difficulty getting numpy to work in blender. I'm running ubuntu 14.04 and Blender 2.77. I've already tried moving the numpy folder into blender/2.77/scripts/modules. No luck. Here is a screenshot of what I get when I try to import numpy in the python interpreter within blender. Numpy works fine outside of blender. Anyone know how to fix this?
I have that issue on another OS, also it's not just blender and numpy. It comes down to numpy using GCC to compile some parts of it (it uses fortran which prevents the use of clang) which is then linked to some libraries supplied by GCC. When numpy is imported it fails to import a compatible version of these libraries and when an older version is found it fails to load.
The reason this happens is blender first loads the older versions of GCC libraries, then when numpy is loaded the pre-loaded library is used as a matching library by name but fails to match the version needed. There has been some indication that cmake is removing rpath settings during linking that leads to this.
The solution is to get blender to load the newer versions so they match the requirements for numpy. Newer library versions include older version compatibility shims that allow programs built with older versions to work with the newer libraries, so it is usually ok to use a newer library version than the program was compiled with.
First locate the libraries installed by GCC, look for copies of libgcc_s.so libgfortran.so and libquadmath.so. They may be in a path like /usr/local/lib/gcc48 or /opt/local/lib/gcc50
Define the environment variable LD_LIBRARY_PATH to include the path to the newest version before starting blender.
The solution I use is a script containing -
#!/bin/sh
export LD_LIBRARY_PATH=/usr/local/lib/gcc49/
exec /usr/local/bin/blender "$#"
which I run instead of running blender directly.
Related
I have two versions of Octave installed, version 3.6.4 installed via the package manager (Linux Mint Debian), and version 4.0.0 compiled from source. I also have numerous .oct files in a folder pointed to in an .octaverc file. My problem is that the version 4.0.0 cannot "see" these .oct files and if I try to call them the whole session crashes unless I recompile them under 4.0.0 with mkoctfile. However, doing this means that the version 3.6.4 cannot "see" them and trying to call them gives an error message
failed to load: liboctinterp.so.3: cannot open shared object file: No such file or directory
How can I get both versions to recognize my .oct functions without having to recompile them each time?
I copy the answer from Mike and Olaf from the help mailinglist (crossposting http://octave.1599824.n4.nabble.com/Oct-files-run-in-Octave-version-3-6-4-or-4-0-0-but-not-both-td4672690.html)
Short answer: you can't.
The Octave library API and ABI change between releases. Octave 3.6 was liboct{ave,interp}.so.1, Octave 3.8 was liboct{ave,interp}.so.2, and 4.0 is liboct{ave,interp}.so.3. These libraries are not forwards or backwards compatible.
You can compile your oct-files in two (or three?) different paths with the
wanted Octave version in the path.
If you want to install your files system-wide, a good candidate directory for the differently compiled oct-files seems to be
fullfile (OCTAVE_HOME (), "lib/octave/site/oct/", octave_config_info ("canonical_host_type"))
assuming OCTAVE_HOME () is different for each of your Octave versions. This directory seems to be in the path by default.
If not system-wide, you could check OCTAVE_VERSION () in your .octaverc and set the path differently for each version.
I installed the latest version of lightGBM(lgb.__version__ == '2.2.1') which is supported by gcc8, but now I have a model already built with lightgbm==2.0.2 which is supported by gcc7.
I need to conform with the previous version, which means I have to downgrade current version of lightgbm, using pip install lightgbm==2.0.2, however when I import it, I met Library not loaded: /usr/local/opt/gcc/lib/gcc/7/libgomp.1.dylib.
I have checked here and here, the problem is I must use lightgbm of previous version.
I assume the problem is caused by gcc version, so is there a way I can install gcc 7?(by the way I tried create a virtualenv on my computer so that I can have both version of lightgbm, also can I install gcc 7 under the virtual environment and keep gcc 8 on my computer as well?)
Thanks soooo much!
So to start off with, it looks like your problem has more to do with gcc than with your python module. While it is a best practice to use virtual environments for each project, that will only effect the lightgbm module and not your gcc version.
To accomplish what you are trying to do, I would recommend taking a look at the following:
Homebrew install specific version of formula?
Their solution is with postgresql but it should translate to most other programs installed with Homebrew.
The only other option I can think of would be to just use the newest versions of lightgbm and gcc but that doesn't appear to be possible for your project.
I have installed the following
C:\MinGW
C:\msys
C:\GTK
But python searching for the files in site packages and throwing the error as:
OSError: cannot load library libcairo.so.2: error 0x7e. Additionally, ctypes.util.find_library() did not manage to locate a library
This issue happening in installation of weasyprint packages.
Installing GTK+ didn't work for me.
I solved this problem using UniConverter2.0.
My environments is
Python 3.7
Windows 10 x64
Install uniconvertor-2.0rc4-win64_headless.msi,
Find the "dll" sub-directory under the UniConverter installation path.(In my case, C:\Program Files\UniConvertor-2.0rc4\dlls)
Add this "dll" path to the system path.
Close VSCode and reopen the project.
Try to run your code again.
Enjoy!
In my experience with this issue Windows 10 (64-bit) with Python 3.5.1, it can be either due to duplicate libraries in other directories seen by PATH that don't work or the libraries that you installed just aren't compatible with your OS/Python bit version.
I suggest installing an older version of GTK+ (I used 3.10.4) using the links provided in the WeasyPrint documentation instead and see if the error persists. I had the issue on a newer build of GTK+. The version of GTK+ installed with MSYS2 gave the same error.
Edit: I found the post where I found the previous version of GTK that I was using but it gave an annoying warning about the cairo version being unstable:
See this post.
Edit 2: To get rid of the cairo version stability warnings, I managed to get a newer version of Cairo using the GTK3-runtime-3.22.8 (Link to git downloads as per WeasyPrint docs)
Remember to uninstall all current GTK+ implementations first. You might get a warning saying that the version of cairo can cause issues but I haven't been able to locate a newer version of cairo that works in windows, let me know if you find one.
I would like to use the Python Pillow library to save 16 bit gray scale arrays in the jp2 ("JPEG 2000") format.
I have hit a brick wall in trying to install the required library OpenJPEG on my Windows machine. The documentation is not very clear... but I assumed that I needed to download the Win64 binaries and simply put them on my path ( which I did).
That done, I am still getting the following error when using Pillow 4.0.0 in Anaconda 4.3.0 on Windows.
IOError: encoder jpeg2k not available
Anyone out there successfully used Pillow to write and read JPEG 2000 files, I would sure appreciate some tips.
Edit:
Here is the code that fails:
import PIL
import numpy as np
arr = np.ones(dtype=np.uint16, shape=(100, 100))
im = PIL.Image.fromarray(arr)
im.save('arr.jp2')
I've just installed Pillow with an installer from here. I chose Pillow-4.0.0.win-amd64-py3.5.exe. During install it found conda's python and properly chose where to install (it installed to a root environment).
Code to test it works:
from PIL import Image
import numpy as np
arr = np.ones(dtype=np.uint16, shape=(100,100))
im = Image.fromarray(arr)
im.save('test.jp2')
Note, that saved file has 8 bpp.
Anaconda build Python using different version of the microsoft visual studio tools.
Each version of those tools has its own runtime, which is incompatible with other versions.
The Pillow library used compiled shared libraries.
You will need to compile OpenJPEG with exactly the same version of the ms visual studio tools that was used to build Python and Pillow.
For general reference.
The Windows equivalent to 'nix .so files have the extension .dll (sic - "Windows Binaries" - dynamic linked library); and yes, the file has to reside somewhere in the system PATH.
Being in the PATH allows Windows to find the file, but that's not enough. Windows has to be told what can be done with it; that it's a shareable library. That's done by:
1) Open a DOS Command Prompt in the (sub)directory where the binary is located; e.g. C:\LIBS
2) Run the command "regsvr32 filename.dll". This registers the .dll as a shared file (in Windows Registry), so that Windows knows how to load it into memory and let user applications access it.
You can actually run regsvr32 from any directory (it's a System file & should be somewhere in the C:\Windows\system32 directory; but it's more convenient to run in the same directory as the .dll because otherwise you have to prepend filename.dll with the entire directory tree from C:\ to where ever the file is located.
You can run "regsvr32" with no target filename to get a popup list of command-line switches which can be used.
I have a problem connected to a version of the openmpi library. Recently I had installed the newest stable version of the openmpi (1.10.2) and one of the programs I use stopped working. There is an error message when I run it:
error while loading shared libraries: libmpi.so.1: cannot open shared object file: No such file or directory
Indeed, there is no such a file in my system. There is however a newer version of the library - libmpi.so.12 and libmpi.so.12.0.2. Other programs, which are using openmpi, work without any error, which proves that the library was installed correctly (at least I think so (: ).
Unfortunately, I don't know which version of the openmpi was used to compile the program. I don't have access to its source code, so I cannot compile it against the newer library. I noticed that I can make the program run if I copy the libmpi.so.12 to the file called libmpi.so.1
Therefore, I have two questions:
Is it reasonable to use the workaround I've found? I have some doubts, although the program appears to run well.
Is there a way to check which version of the openmpi library was used during a compilation?
Thanks in advance.
EDIT:
I use Linux Mint 17.3.