From: Peter Korsgaard <jacmet@uclibc.org>
To: buildroot@busybox.net
Subject: [Buildroot] dbus-binding-tool
Date: Tue, 06 Oct 2009 23:05:56 +0200 [thread overview]
Message-ID: <87k4z81bd7.fsf@macbook.be.48ers.dk> (raw)
In-Reply-To: <1254861734.11487.8.camel@bender> (Sven Neumann's message of "Tue\, 06 Oct 2009 22\:42\:14 +0200")
>>>>> "Sven" == Sven Neumann <s.neumann@raumfeld.com> writes:
Sven> Hi,
Sven> we are using the dbus-binding-tool from host-dbus-glib in one of our
Sven> packages and today I found that the dbus-binding-tool binary calls
Sven> 'glib-genmarshal'. So unless dbus-binding-tool is called with the PATH
Sven> adjusted to include host_dir/usr/bin before the system path, it will
Sven> fail in case that no glib-genmarshal is available on the host system.
Sven> I wonder how this should best be handled. For now I have adjusted our
Sven> build to call make with the PATH environment variable adjusted similar
Sven> to how Makefile.autotools.in does it. Should this be the recommended way
Sven> to call make or should we rather patch dbus-binding-tool in the
Sven> host-dbus-glib compile to explicitly call glib-genmarshal from
Sven> host_dir ?
From a quick look at the dbus-glib code, it seems to be a mistake that
they are explicitly calling glib-genmarshal, as the configure script
already gets the correct filename from pkg-config.
Maybe the cleanest solution would be to patch dbus-binding-tool to use
GLIB_GENMARSHAL, and then ensure that the host version of glib-2.0.pc
contains the full path to glib-genmarshal (or let configure add
$prefix/bin in front)? Upstream might even be willing to accept such a
patch.
Otherwise, simply changing DBUS_GLIB_HOST_BINARY to be
PATH=.. dbus-binding-tool or making a shellscript wrapper which sets the
path might be the easiest solution.
--
Bye, Peter Korsgaard
prev parent reply other threads:[~2009-10-06 21:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-06 20:42 [Buildroot] dbus-binding-tool Sven Neumann
2009-10-06 21:05 ` Peter Korsgaard [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k4z81bd7.fsf@macbook.be.48ers.dk \
--to=jacmet@uclibc.org \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.