powerpc64: graphics/mesa-dri fails to build because "ImportError: No module named mako.template"

Mark Millard markmi at dsl-only.net
Sat Dec 30 10:04:52 UTC 2017


On 2017-Dec-30, at 1:09 AM, Jan Beich <jbeich at FreeBSD.org> wrote:

> Mark Millard <markmi at dsl-only.net> writes:
> 
>> [I experiment with system clang based powerpc64 and powerpc
>> builds. For powerpc64, linking pkg requires using a ports
>> binutils instead of the system binutils. This blocks using
>> poudriere. So portmaster is in use here.]
> 
> Would be nice if you cheat by replacing /usr/bin/ld instead.
> portmaster may miss some issues due to building in a dirty environment.

I use poudriere elsewhere, even on a rpi2. I'm familiar with
portmaster's issues/limitations.

I report problems to FreeBSD and llvm based on what I run
into, including reporting the pkg bootstrap problem under
poudriere. I try to be fairly normal in how things are
used for such experiments. (The system binutils was able to
link pkg until fairly recent clang updates.) The purpose of
the experiments is to make the bugzilla submittals or list
reports for what I run into.


>> 
>> On 2017-Dec-29, at 11:36 PM, Mark Millard <markmi at dsl-only.net> wrote:
>> 
>>> gmake[5]: Entering directory '/wrkdirs/usr/ports/graphics/mesa-dri/work/mesa-17.3.1/src/amd/vulkan'
>>> python2.7 ./radv_entrypoints_gen.py \
>>> 	--xml ../../../src/vulkan/registry/vk.xml --outdir .
>>> Traceback (most recent call last):
>>> File "./radv_entrypoints_gen.py", line 30, in <module>
>>>   from mako.template import Template
>>> ImportError: No module named mako.template
> 
> Fixed by https://svnweb.freebsd.org/changeset/ports/457591
> Vulkan drivers always need py-mako since Mesa 17.3 but I didn't
> try building only radv (either anv + radv or none).

Cool. Thanks.

>> freshports indicated:
>> 
>> 	• py27-mako>0 : textproc/py-mako at py27
>> 
>> as a build dependency but portmaster did not
>> try to create a textproc/py-mako at py27 on
>> its own.
> 
> freshports generates dependency list on amd64 but radv was also
> built on powerpc*.

I'm aware that freshports is not based on powerpc64. But it
was enough to give me the hint as to where mako.template
comes from since I was not familiar with it (or mesa-dri
or vulkan).


Side note:

I used to to use the following to deal with
the binutils issue, until clang progressed
and system binutils no longer worked for pkg:

# more /usr/local/etc/poudriere.d/make.conf 
. . .
# The system clang for TARGET_ARCH=powerpc64
# and the system binutils (such as ld) do not
# (yet?) mix well. So for ports use the
# devel/binutils ones. (A problem before
# they are already in place!)
.if ${.CURDIR:M*/devel/binutils}
.elif ${.CURDIR:M*/math/gmp}
.elif ${.CURDIR:M*/math/mpfr}
.elif ${.CURDIR:M*/devel/bison}
.elif ${.CURDIR:M*/devel/gmake}
.elif ${.CURDIR:M*/devel/gettext-tools}
.elif ${.CURDIR:M*/print/indexinfo}
.elif ${.CURDIR:M*/devel/gettext-runtime}
.elif ${.CURDIR:M*/ports-mgmt/pkg}
.elif ${.CURDIR:M*/devel/m4}
.elif ${.CURDIR:M*/lang/perl5.*}
.elif ${.CURDIR:M*/print/texinfo}
.elif ${.CURDIR:M*/misc/help2man}
.elif ${.CURDIR:M*/devel/p5-Locale-gettext}
.else
USE_BINUTILS=
#
# devel/powerpc64-gcc builds end up using /usr/bin/ld
# in places during the build anyway, so try to
# separately force the issue to avoid the resulting
# error(s). (By contrast lang/gcc7 built fine
# without such additions.)
CFLAGS+=-B${LOCALBASE}/bin/
CXXFLAGS+=-B${LOCALBASE}/bin/
CPPFLAGS+=-B${LOCALBASE}/bin/
.endif

Basically: devel/binutils and the ports that needed
to build before it did not use USE_BINUTILS= in their
builds --but the rest of the built ports did.

===
Mark Millard
markmi at dsl-only.net



More information about the freebsd-ports mailing list