From: Jon Loeliger <jdl@bigfootnetworks.com>
To: "Luis R. Rodriguez" <mcgrof@gmail.com>
Cc: Pavel Roskin <proski@gnu.org>,
linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [Fwd: Re: [PATCH 4/5] Introduce separate HOST and TARGET compilation steps.]
Date: Wed, 01 Jul 2009 13:50:40 -0500 [thread overview]
Message-ID: <1246474240.11632.27.camel@jdl-desktop> (raw)
In-Reply-To: <43e72e890907011049w45508c9fpfabdddf36c28e99c@mail.gmail.com>
On Wed, 2009-07-01 at 10:49 -0700, Luis R. Rodriguez wrote:
> On Wed, Jul 1, 2009 at 10:46 AM, Jon Loeliger<jdl@bigfootnetworks.com> wrote:
> > On Wed, 2009-07-01 at 10:35 -0700, Luis R. Rodriguez wrote:
> >> On Wed, Jul 1, 2009 at 10:30 AM, Jon Loeliger<jdl@bigfootnetworks.com> wrote:
> >>
> >> > Do you agree or disagree with me when I say that the regdbdump program
> >> > might need to be compiled twice -- once for the host and once for the
> >> > target?
> >>
> >> Why?
> >
> > The existing binary regulatory DB binary is verified on the host
> > using these rules. (This is from my version of the makefile, but
> > they are there in the original too.):
> >
> > all: host target $(REG_BIN) $(BUILD_ALL) verify
> >
> > verify: $(REG_BIN) host/regdbdump
> > $(NQ) ' CHK $(REG_BIN)'
> > $(Q)./host/regdbdump $(REG_BIN) >/dev/null
> >
> > That is, as part of the host build process, the regdbdump tool
> > is run *on the host*.
>
> This helps to understand a little better some of your intentions, may
> be good to mention this as part of your patches. Hm, interesting... I
> suppose we don't want to just disable this check then.
Luis,
Shall I supply more or different information than what
was in my git log message?:
The regdbdump tool is really a host executable that is used
during the build process. It could also be installed and
used on the target, but two separate compilations are needed
to achieve that goal.
Currently, regdbdump is only built for the target, and thus
cross-compilation of the tool is really feasible without
this patch (or one like it).
Signed-off-by: Jon Loeliger <jdl@bigfootnetworks.com>
Though, we should s/feasible/infeasible/ there too. :-)
> > Ultimately, the regdbdump utility may *also* be needed or
> > wanted on the target too.
>
> ACK.
>
> Luis
Thanks,
jdl
prev parent reply other threads:[~2009-07-01 18:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1246460365.11632.4.camel@jdl-desktop>
[not found] ` <43e72e890907010959q15bde116ue796802e006e410f@mail.gmail.com>
[not found] ` <1246468471.15757.12.camel@mj>
[not found] ` <1246469405.11632.19.camel@jdl-desktop>
[not found] ` <43e72e890907011035x77005470u6646d7feb941b9f7@mail.gmail.com>
[not found] ` <1246470361.11632.23.camel@jdl-desktop>
2009-07-01 17:49 ` [Fwd: Re: [PATCH 4/5] Introduce separate HOST and TARGET compilation steps.] Luis R. Rodriguez
2009-07-01 18:50 ` Jon Loeliger [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=1246474240.11632.27.camel@jdl-desktop \
--to=jdl@bigfootnetworks.com \
--cc=linux-wireless@vger.kernel.org \
--cc=mcgrof@gmail.com \
--cc=proski@gnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).