Python3.4 error - Cannot enable executable stack as shared object requires: Invalid argument

Question

I've been trying to install OpenCV in a Bash on Windows (Windows Subsystem for Linux, wsl) environment and it's been proving very difficult.

I think I'm getting very close, but upon entering python, import cv2 gives the following error:

ImportError: libopencv_core.so.3.1: cannot enable executable stack as shared object requires: Invalid argument

How do I enable the library to execute on the stack?

---

My OpenCV *opencv*.so* library files are located in /usr/local/lib/. In a normal Linux environment, I would grant these libraries the ability to execute on the stack using

execstack -c /usr/local/lib/*opencv*.so*

However, even though I can successfully download the execstack package, it isn't a recognized command I can run to allow execution on the stack. I suspect this has something to do with Data Execution Prevention, Window's version of Exec-Shield to prevent stack smashing attacks.

But maybe I've just been too close to the problem to figure out what's wrong. Why can't I import this python package? I'm using Python v3.4 and OpenCV compiled from the latest source code (v.3.1).

Answer 1

I solved this problem following this:tatsuya-y.hatenablog.com

I use windows bash and install opencv by conda install -c menpo opencv3=3.1.0 then I got this (python 2.7) >>>import cv2 Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: libopencv_ccalib.so.3.1: cannot enable executable stack as shared object requires: Invalid argument

I solve it by execstackcommand

sudo apt-get install execstack
sudo execstack -c $HOME/anaconda2/lib/libopencv_*

Then sudo apt-get install gtk2.0-0 Problem solved! >>> cv2.__version__ '3.1.0'

Remember that the opencv libraries are installed to /usr/local/lib if following the installation instructions online. Thus, the command would be:

sudo execstack -c /usr/local/lib/libopencv_*

Answer 2

There are lots of things that simply don't work at the moment, because there are either unimplemented syscalls (WSL only has partial coverage, only about 70% of syscalls are implemented, some of them only partially), or missing socket modes and options (WSL does not yet support Unix datagram sockets, although it should be available in the next insider build).

If you go to the github (BashOnWindows) and post an strace or search for your issue and find a copy of it, that's the best way to get an answer. The Microsoft team working on this project wants lots and lots of feedback and bugtesting.

To be clear, I am saying that you are 100% running into something that isn't implemented yet. However, there might be a way, if you look at the sourcecode for your .so file to disable the part of the code that uses that syscall (since Python is crossplatform and not all Linux syscalls are supported across all *nix operating systems).