[oe] Python-dbus build error

[Thom Nichols]

Follow-up - I've found my problem; pyexecdir and pythondir were defined like
this in the Makefiles:

pyexecdir = ${exec_prefix}lib/python2.6/site-packages
pythondir = ${prefix}lib/python2.6/site-packages

They're missing a leading / so lib/python2.6/site-packages looks like
relative path when it should just be /lib/python2.6/site-packages.

So this would appear to be a bug...  The value comes from the configure
script but I'm not sure how to fix it.  I just fixed the Makefiles
manually.  Any suggestions on how I can fix the source of the problem or if
I should open an issue?  Please let me know how I can help.

Thanks.
-Thom


On Fri, Jun 4, 2010 at 10:51 AM, Thom Nichols <tmnichols at gmail.com> wrote:

> Hello OE wizards!
>
> I'm experiencing an error building python-dbus_0.83.0:
>
> | Making all in _dbus_bindings
> | make[2]: Entering directory
> `/home/tnichols/dev/oe/build/tmp/work/armv5te-oe-linux-gnueabi/python-dbus-0.83.0-ml2/dbus-python-0.83.0/_dbus_bindings'
> | /bin/sh ../arm-oe-linux-gnueabi-libtool --tag=CC   --mode=link
> arm-oe-linux-gnueabi-gcc -march=armv5te -mtune=arm926ej-s -mthumb-interwork
> -mthumb
> -isystem/home/tnichols/dev/oe/build/tmp/sysroots/armv5te-oe-linux-gnueabi/include
> -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -Wall
> -Wextra -Wno-missing-field-initializers -Wdeclaration-after-statement
> -Wshadow -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
> -Wdeprecated-declarations -std=c9x -fno-strict-aliasing -module
> -avoid-version -export-symbols-regex init_dbus_bindings
> -L/home/tnichols/dev/oe/build/tmp/sysroots/armv5te-oe-linux-gnueabi/lib
> -ldbus-1 -lpthread -lrt
> -L/home/tnichols/dev/oe/build/tmp/sysroots/armv5te-oe-linux-gnueabi/lib
> -Wl,-rpath-link,/home/tnichols/dev/oe/build/tmp/sysroots/armv5te-oe-linux-gnueabi/lib
> -Wl,-O1 -Wl,--hash-style=gnu -o _dbus_bindings.la -rpath
> lib/python2.6/site-packages abstract.lo bus.lo bytes.lo conn.lo
> conn-methods.lo containers.lo debug.lo exceptions.lo float.lo generic.lo
> int.lo libdbusconn.lo mainloop.lo message-append.lo message.lo
> message-get-args.lo module.lo pending-call.lo server.lo signature.lo
> string.lo validation.lo
> | arm-oe-linux-gnueabi-libtool: link: only absolute run-paths are allowed
>
>
> Which I think is referring to this arg: -rpath lib/python2.6/site-packages.
>
> Now that path is the value of $(pyexecdir) which is defined as: pyexecdir =
> ${exec_prefix}lib/python2.6/site-packages  in _dbus_bindings/Makefile. The
> command in the Makefile looks like this:
> _dbus_bindings.la: $(_dbus_bindings_la_OBJECTS)
> $(_dbus_bindings_la_DEPENDENCIES)
>     $(LINK) -rpath $(pyexecdir) $(_dbus_bindings_la_OBJECTS)
> $(_dbus_bindings_la_LIBADD) $(LIBS)
>
> I also see other locations in the makefile where it uses:
> $(DESTDIR)$(pyexecdir).  However, modifying the -rpath line to read -rpath
> $(DESTDIR)$(pyexecdir) doesn't seem to help.
>
> So it appears that all of $(DESTDIR), ${exec_prefix} and ${prefix} (one of
> which I would hope points to
> /home/tnichols/dev/oe/build/tmp/sysroots/armv5te-oe-linux-gnueabi in my
> case) are all unset (or the empty string...)  I'm not a make expert; where
> do these variables get set?  More specifically, since $(pyexecdir) is
> defined as ${exec_prefix}lib/python2.6/site-packages, I'm guessing
> ${exec_prefix} is what I'm looking for.
>
> Also, is this an openembedded bug or a python-dbus bug?
>
> Thanks in advance for the help.
>
> -Thom
>
>
>