[Arm-dev] Success with Avnet PicoZed (Xilinx Zynq), Suggestions for building python-matplotlib

Paul Graham

pgrahamdev at gmail.com
Thu Jul 6 19:42:58 UTC 2017


Hi,

I wanted to let you know that I have had success with running the CentOS 7
userland on an Avnet PicoZed module using the Xilinx-provided source for
the kernel and U-Boot available on their GitHub project (using the
"xilinx-v2016.1.01" tag for the kernel source and the "xilinx-v2016.1" tag
for U-Boot).

We have been running Fedora 20 ARM on these modules (with the same kernel
and version of U-Boot) for a little while and thought we would try out
CentOS for various reasons (longer term support, similarity to RHEL 7,
etc.).

One challenge I have run into, though, is that our software depends on
"python-matplotlib" and a few other packages that haven't been prebuilt for
CentOS 7 (but were available under Fedora 20 ARM).  I was able to
successfully build a number of these packages from source RPMs, but
building "python-matplotlib" is starting to get a bit complicated,
especially, with what appears to be some circular build dependencies among
the source packages.  For example, here is one set of dependencies leading
to what appears to be a circular dependency:

python-matplotlib -> gtk2-devel
gtk2 SRPM (for gtk2-devel) -> pango-devel
pango SRPM (for pango-devel) -> harfbuzz-devel
harfbuzz SRPM (for harfbuzz-devel) -> graphite2-devel
graphite2 SRPM (for graphite2-devel) -> asciidoc
asciidoc SRPM (for asciidoc) -> graphviz
graphviz SRPM (for graphviz)-> gtk2-devel, pango-devel, etc.

Similarly, there is also the following circular dependency, starting with
asciidoc:

...
asciidoc -> dblatex
dblatex SRPM (for dblatex) -> texlive-collection-xetex
texlive SRPM (for texlive-collection-xetex) -> gtk2-devel, pango-devel, etc.

Any suggestions for how to deal with these apparent circular dependencies?
I have been building the RPMs by hand with "rpmbuild --rebuild <source
RPM>" trying to work through the dependencies and installing as many binary
packages as are available.  Clearly, there must be some way to deal with
this since these packages have been built successfully for other
architectures.

Thanks,

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20170706/36d28ebb/attachment.html>


More information about the Arm-dev mailing list