Ubuntu 20.04 missing libffi 6 causing bundled python 3 to fail on ctypes import

[braingram]

I installed fomu-toolchain-linux_x86_64-v1.5.6 on Ubuntu 20.04 which lacks libffi 6 (7 is the only package in the repos). Working through the workshop I encountered an error building blink.py in the migen section. The same error can be seen when trying to import ctypes with the python3 included in the toolchain.

>>python3 -c "import ctypes"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/brett/Repositories/im-tomu/fomu-workshop/fomu-toolchain-linux_x86_64-v1.5.6/lib/python3.6/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ImportError: libffi.so.6: cannot open shared object file: No such file or directory

Some other system information:

>>lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.1 LTS
Release:	20.04
Codename:	focal

>>dpkg -l | grep libffi
ii  libffi-dev:amd64                           3.3-4                                   amd64        Foreign Function Interface library (development files)
ii  libffi7:amd64                              3.3-4                                   amd64        Foreign Function Interface library runtime

>>apt search libffi6
Sorting... Done
Full Text Search... Done

Also, I can successfully run the blink.py script with my system python.

[xobs]

I'm unsure of how to correctly handle this.

We don't actually include Python. We include enough of Python to support nextpnr, which requires Python to support multiple clock domains.

Unfortunately, Python appears to be very difficult to embed, and it looks like it's leaking into your environment somehow.

I'm open to suggestions on how to fix this.

[braingram]

I'm also not sure the correct way to handle this. I tried a few things:

1. Statically compile python: I made a few attempts at this with no luck.

2. Modify LD_LIBRARY_PATH: Including libffi.so.6 in the toolchain lib directory and adding that path to LD_LIBRARY_PATH appears to work. Going this route would mean adding the .deb to toolchain-nextpnr-ice40 (with the python .debs) and modifying the toolchain install instructions to mention the LD_LIBRARY_PATH modification for linux systems without libffi 6.

3. Remove ctypes from bundled python: I looked into removing ctypes as migen only uses it on cygwin (but imports it for all systems which causes the exception). However, litex also use ctypes. From what I can tell litex uses ctypes on cygwin and in comm_pcie.py. I'm not sure when comm_pcie.py is used but if I replace the init.py inside ctypes for the bundled python with a blank file both migen and litex appear to be working. I'm very new to migen and litex and only tested the commands provided in the workshop (which is awesome btw).

Number 2 seems the cleanest but does make setting up the tool chain a bit more involved. It would require changes to toolchain-nextpnr-ice40 (adding the libffi deb) and this repo. Number 3 should only require changes to toolchain-nextpnr-ice40 but leaves the toolchain with a less-than complete python and could have unintended consequences.

If you're happy with either option I can make the changes and pull requests.

[mithro]

@xobs Rather than maintaining our own toolchain, maybe we should change the instructions to use the tools from https://github.com/open-tool-forge/fpga-toolchain?

[xobs]

I do think @mithro has a good idea here. fpga-toolchain has settled into a steady-state now and appears to be functional. And is certainly more up-to-date.

Does that package have the same issues for you, @braingram ?

[braingram]

@xobs It looks like fpga-toolchain builds python against libffi 7 so it works on Ubuntu 20.04. I'm not if it'll work with 18.04 which may only have libffi 6 (from the repos):

>>ldd fpga-toolchain/lib/python3.8/lib-dynload/_ctypes.cpython-38-x86_64-linux-gnu.so 
	linux-vdso.so.1 (0x00007fffbbdf9000)
	libffi.so.7 => /usr/lib/x86_64-linux-gnu/libffi.so.7 (0x00007f55f8cc1000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f55f8cbb000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f55f8c98000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f55f8aa6000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f55f8d1b000)

I was able to build the migen and litex portions of the workshop with fpga-toolchain. I did not test it with the hardware. dfu-util is included with fpga-toolchain but wishbone-tool is not. I'm not sure about other parts of the workshop.

[fidergo-stephane-gourichon]

I had the same problem and resolved it via straight manual install of libffi6 from *buntu 18.04's repos.

You can download one for your architecture on https://packages.ubuntu.com/bionic/libffi6 and then dpkg --install libffi6*.deb

Generally, mixing packages from different releases is not a good idea. In some cases it works very well. A cleaner alternative would be to compile from source, so far it just works as is.

[tcal-x]

You can download one for your architecture on https://packages.ubuntu.com/bionic/libffi6 and then dpkg --install libffi6*.deb

I hit this issue too, and this worked for me.

[umarcor]

In #20, the inclusion of Python3 is removed. Instead, open-tool-forge/fpga-toolchain is included and the user is expected to have Python3 available on the system. I'd be glad to have some feedback. In the PR you will find links to the artifacts.

[xobs]

From my reading of the build outputs, doesn't open-tool-forge/fpga-toolchain have the exact same problem?

On Windows, they rename python.exe to python3-private.exe, and they still include lib/python3.8. That means we could simply tell users to run python3-private.exe to e.g. build litex examples.

On Linux, they also include lib/python3.8, which pollutes the system in the same way as reported in the original issue.

I do agree that it's a good idea to assume Linux users have Python installed, due to widely varying installations, ABIs, and path settings. I'm less certain about assuming Mac users have Python installed.

[umarcor]

@xobs, you are correct. The main point is that, because fpga-toolchain adds python privately, merging it with the one currently in this toolchain would produce lots of conflicts. Hence, I "decided" to drop the one from here in favour of the "private" one in fpga-toolchain (which comes in the "pack"), and move this discussion to open-tool-forge/fpga-toolchain.

I tested it on Windows 10 (MINGW64 from MSYS2), and there I did need to install Python3 for running LiteX examples. Note: that's a different Python install from the one used in CI. Nonetheless, both of them work as expected. This is to say that, even if Windows users don't have Python installed, all they need to do is download the regular zip/exe from https://www.python.org/, or use their preferred package manager (pacman, chocolatey, ninite...). Anyway, I would expect almost all users nowadays to have Python because of any other project/tool.

[edbordin]

Hmm, as @xobs says I'm using a very similar method to fomu-toolchain for embedding python for nextpnr. I deliberately didn't put the python executable in the path to try and avoid this sort of thing, (except on windows where I added it as python3-private.exe to make the symbiyosys launcher work).

Is the problem that python searches PATH and finds lib/python3.8, or is that problem that python3 is included in bin by fomu-toolchain? If it's the former this bug is relevant to me too...

[xobs]

No, I think @edbordin is doing it correctly -- I had forgotten that I ended up shipping python3 on Linux, which is the source of this issue. Removing python3 and relying on the user to supply their own Python solves the problem.