Category: Jetson Nano

building python 3.8.3 on jetpack 4.4 developer preview

whbeebe

We’re going to be installing Python 3.8.3 onto the Jetson Nano. Every current version of Jetson Nano’s JetPack Development Kit is built and hosted on Ubuntu 18.04. Ubuntu 18.04 comes stock with Python 3.6.9. We want to use a more up-to-date version of Python, but not clobber the default version. Installing the up-to-date version side-by-side with the default Ubuntu version will be accomplished with the alternate installation provided by Python’s make process.

  1. Download the source from https://www.python.org/downloads/. In this post it was Python 3.8.3
  2. Untar the file:
    tar xvf Downloads/Python-3.8.3.tar.xz
  3. Make a build directory at the same level as the source directory. In this case it was named build-python-3.8.3
  4. Change directory into the build directory.
  5. From within the build directory execute the configure script:
    ../Python-3.8.3/configure --enable-optimizations
  6. Run make:
    make -j 4
  7. Install into the alternate location for this version of Python:
    sudo -H make altinstall
  8. Check for the alternate location with ‘which python3.8’. It should return ‘/usr/local/bin/python3.8’.

Python 3.8.3 will build and be functional as is, but if you want all the features to build for Python you’ll need to install a list of additional libraries in order to enable all the features, or at least as many as you care about.

My list of imported libraries for this build includes:

  • libgdm-dev
  • libnss3-dev
  • libssl-dev
  • libsqlite3-dev
  • libreadline-dev
  • libbz2-dev
  • libdb-dev, libdb++-dev (Berkeley db)
  • libgdbm-dev

Why the additional libraries? Because this is what happened when I built in my unique environment the first time (First run).

# First runPython build finished successfully!The necessary bits to build these optional modules were not found:_bz2  _dbm  _gdbm  _hashlib  _sqlite3  _ssl   _tkinter  readline To find the necessary bits, look in setup.py in detect_modules() for the module's name.The following modules found by detect_modules() in setup.py, have beenbuilt by the Makefile instead, as configured by the Setup files:_abc  atexitpwdtime   Could not build the ssl module!Python requires an OpenSSL 1.0.2 or 1.1 compatible libssl with X509_VERIFY_PARAM_set1_host().LibreSSL 2.6.4 and earlier do not provide the necessary APIs, https://github.com/libressl-portable/portable/issues/381# Second runPython build finished successfully!The necessary bits to build these optional modules were not found:_tkinter   To find the necessary bits, look in setup.py in detect_modules() for the module's name.The following modules found by detect_modules() in setup.py, have beenbuilt by the Makefile instead, as configured by the Setup files:_abc  atexitpwdtime

It took two attempts, the first to have make list the modules that wouldn’t be built at the end of a full build. I went looking in both the Bash script function ‘detect_modules()’ as well as on the web, and managed to install support for everything I cared about. The only module I didn’t care to build was tkinter. Tkinter is the interface to the Tk GUI toolkit. I use PyQt5 instead, so found no need to build it. Your needs, of course, may vary, and it may come to pass I need a package that uses Tcl/Tk GUI. But I doubt that.

Once Python 3.8.3 was built I created a virtual environment according to the directions here: https://docs.python.org/3/library/venv.html . Just as I didn’t want this latest version installed over the stock Python 3.6.9, I’m using a virtual environment to keep usage of 3.8.3 from corrupting the stock environment. In my environment I create an alias to execute ‘activate’. One nice feature of a virtual environment is that ‘python’ points to Python 3.8.3.

More to come…

building emacs 28 on jetpack 4.4 developer preview

whbeebe

By now all of this blog’s readers should realize that when I write about Nvidia’s Jetpack 4.4 Developer Preview (here-after called JP44), I mean the version of Ubuntu 18.04.4 with Nvidia’s software extensions and packages installed.

Earlier I installed all the bits and bobs necessary to build Visual Studio Code on JP44, and managed to get it up and running, mostly. That is, it would open and edit files, it handled syntax highlighting for the sources I cared about, and at least it allowed me to install two extensions. The big problem is that after that first extension installation, the extension list is now empty, meaning I can’t install any others. And I wrote I’d probably stick with it regardless.

Then I remembered I’d extended and configured both Vim and Emacs into very useful tools on my RPi4. I powered up the RPi4 and copied my Vim and Emacs configuration files over to the Jetson Nano and JP44. Easy, right?

For Vim there wasn’t an issue. Everything ran just fine. Emacs installed from the repo was different. I knew I had a problem when the following line in my .emacs file failed on startup with the local emacs:

(global-display-line-numbers-mode)

I checked the version of emacs installed on JP44, and sure enough, it was version 25, one major release back from the version installed on my RPi4 and Raspbian. No, I wasn’t going to change that line (and a few others) back to the older way of doing things. Instead I went over to the Project Emacs page on Savannah ( http://savannah.gnu.org/projects/emacs/ ), followed the directions there to clone from their GitHub repo hosted on Savanah, and went about the business of building an up-to-date emacs.

First time through I was missing a few needed development libraries. I got those installed, got a proper configuration, and then built it. When I fired it up I was horrified to see it was using old school X fonts on everything. Not an anti-aliased font in sight. That just sucked, so I starting looking at the configure output and installing all the necessary libraries emacs needed to support anti aliased fonts. The full list of necessary installs are:

  • texinfo
  • libxaw7-dev
  • libjpeg-dev
  • libpng-dev
  • libgif-dev
  • libtiff-dev
  • gnutls-dev
  • libncurses-dev
  • libfreetype6-dev
  • libcairo-dev

Some of those libraries are needed just to get configure to finish at all. They are listed in the order they were installed. After installing the freetype developer library I got the following interesting warning from configure:

configure: WARNING: This configuration uses libXft, which has a number offont rendering issues, and is being considered for removal in thenext release of Emacs.  Please consider using Cairo graphics +HarfBuzz text shaping instead (they are auto-detected if therelevant development headers are installed).

Ok. That’s when I installed libcairo-dev. After that it configured and then built. ‘make install’ puts the binary in /usr/local/bin. When I opened up emacs the second time, it was lovely to behold.

Fonts everywhere are nicely rendered and anti-aliased. You’ll note also that this is emacs version 28, which is fine by me. It works with Go, C/C++, Python, and bash, which is all I really need. I also noticed that emac’s memory footprint is tiny compared to VSCode. Which is ironic considering that in the days when men used Vaxen and 1MiB of memory was considered a luxury, emacs was frowned upon by sysadmins who didn’t like how too many emacs sessions could tax those mighty Vaxen. Now I run it on a $100 quad-core 64-bit computer with 4GiB of memory because it’s lean and mean compared to other equivalent tools. My how the times have changed.