From: Jon Loeliger <jdl@bigfootnetworks.com>
To: Pavel Roskin <proski@gnu.org>
Cc: linux-wireless@vger.kernel.org
Subject: Re: RFC: cross-building crda
Date: Fri, 12 Jun 2009 16:37:09 -0500 [thread overview]
Message-ID: <1244842629.18211.429.camel@jdl-desktop> (raw)
In-Reply-To: <1244760685.6544.6.camel@mj>
On Thu, 2009-06-11 at 18:51 -0400, Pavel Roskin wrote:
> This sounds too complicated.
Hi Pavel,
Thanks for your feedback.
> No other popular software does it,
That's just flat not true. Even Linux itself separates the
components that need to be built for the host from those that
need to be built for the target machine. The Kconfig, dtc and
other tools in the scripts directory, for example, are host
tools are built and used during the rest of the target build.
> yet
> somehow it can be cross-compiled. I'm not talking about such software
> as kernels, compilers and other tools that need to know specific
> characteristics of the target.
Thanks, I get that.
> Please check the sources of buildroot (http://buildroot.uclibc.org/) to
And that. Really, I get the whole cross compile thing.
And its environment. Mine happens to be LTIB for PowerPC
and I'm using a powerpc-e300-linux-gnu- toolchain to do so.
> see how it manages to cross-compile a lot of programs that don't do
> anything specific to support cross-compilation.
The bulk of the CRDA correctly cross compiles by simply using
and setting CC to allow for CROSS_COMPILE like this:
CC := $(CROSS_COMPILE)gcc
That's not the problem.
> Sometimes minimal
> patches are needed, but nothing nearly as intrusive as your proposal.
The build of regdbdump needs to be split out as a *host* tool.
It is used on the *host* to verify the regulatory.bin database.
It shouldn't need, nor does it use, for example, the libnl that
is currently supplied on the link line for that executable.
That libnl is the *target*'s library for target linking.
Furthermore, this same distinction applies to the grcypt/openssl
library that is selected. In fact, if regdump is built once
for the host and once for the target, you may need different
crypto mechanism selections for each.
You can see the same distinction in kconfig's Makefile where it
says this around line 95:
96 # Use recursively expanded variables so we do not call gcc unless
97 # we really need to do so. (Do not call gcc as part of make mrproper)
98 HOST_EXTRACFLAGS = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ccflags)
99 HOST_LOADLIBES = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ldflags $(HOSTCC))
100
101 HOST_EXTRACFLAGS += -DLOCALE
All I'm doing is the same HOST tool separation for CRDA.
RFC patch for comments to follow.
Thanks,
jdl
prev parent reply other threads:[~2009-06-12 21:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-11 15:21 RFC: cross-building crda Jon Loeliger
2009-06-11 22:51 ` Pavel Roskin
2009-06-12 21:37 ` 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=1244842629.18211.429.camel@jdl-desktop \
--to=jdl@bigfootnetworks.com \
--cc=linux-wireless@vger.kernel.org \
--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).