linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* CRDA and cross-compilation
@ 2009-08-06  8:08 Philip A. Prindeville
  2009-08-06 14:46 ` Jon Loeliger
  2009-08-06 15:09 ` John W. Linville
  0 siblings, 2 replies; 22+ messages in thread
From: Philip A. Prindeville @ 2009-08-06  8:08 UTC (permalink / raw)
  To: linux-wireless

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

Who currently owns CRDA?

I started to stare at cross-compiling issues, but realized that we need
two versions of reglib.o and print-regdom.o...

One to link with regdumpdb (compiled with HOSTCC) and one to link with
everything else (compiled with TARGET_CC)...

No easy way to do this without a lot of changes.

Here's what I have so far.


[-- Attachment #2: crda-cross-compile.patch --]
[-- Type: text/plain, Size: 2266 bytes --]

--- crda-1.1.0/Makefile.orig	2009-04-17 14:49:45.000000000 -0700
+++ crda-1.1.0/Makefile	2009-08-06 00:53:47.000000000 -0700
@@ -1,6 +1,6 @@
 # Modify as you see fit, note this is built into crda,
 # so if you change it here you will have to change crda.c
-REG_BIN?=/usr/lib/crda/regulatory.bin
+REG_BIN?=$(DESTDIR)/usr/lib/crda/regulatory.bin
 REG_GIT?=git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-regdb.git
 
 PREFIX ?= /usr/
@@ -22,46 +22,74 @@ UDEV_RULE_DIR?=/lib/udev/rules.d/
 # with make PUBKEY_DIR=/usr/lib/crda/pubkeys
 PUBKEY_DIR?=pubkeys
 
+MKDIR ?= mkdir -p
+INSTALL ?= install
+
 CFLAGS += -Wall -g
 
 all: $(REG_BIN) crda intersect verify
 
-ifeq ($(USE_OPENSSL),1)
+ifeq ($(CROSS_COMPILE),)
+
+ ifeq ($(USE_OPENSSL),1)
 CFLAGS += -DUSE_OPENSSL `pkg-config --cflags openssl`
 LDLIBS += `pkg-config --libs openssl`
 
 reglib.o: keys-ssl.c
 
-else
+ else
 CFLAGS += -DUSE_GCRYPT
 LDLIBS += -lgcrypt
 
 reglib.o: keys-gcrypt.c
 
-endif
-MKDIR ?= mkdir -p
-INSTALL ?= install
+ endif
 
 NL1FOUND := $(shell pkg-config --atleast-version=1 libnl-1 && echo Y)
 NL2FOUND := $(shell pkg-config --atleast-version=2 libnl-2.0 && echo Y)
 
-ifeq ($(NL1FOUND),Y)
+ ifeq ($(NL1FOUND),Y)
 NLLIBNAME = libnl-1
-endif
+ endif
 
-ifeq ($(NL2FOUND),Y)
+ ifeq ($(NL2FOUND),Y)
 CFLAGS += -DCONFIG_LIBNL20
 NLLIBS += -lnl-genl
 NLLIBNAME = libnl-2.0
-endif
+ endif
 
-ifeq ($(NLLIBNAME),)
+ ifeq ($(NLLIBNAME),)
 $(error Cannot find development files for any supported version of libnl)
-endif
+ endif
 
 NLLIBS += `pkg-config --libs $(NLLIBNAME)`
 CFLAGS += `pkg-config --cflags $(NLLIBNAME)`
 
+else
+
+ ifeq ($(USE_OPENSSL),1)
+CFLAGS += -DUSE_OPENSSL
+LDLIBS += -lssl
+
+reglib.o: keys-ssl.c
+
+ else
+CFLAGS += -DUSE_GCRYPT
+LDLIBS += -lgcrypt
+
+reglib.o: keys-gcrypt.c
+
+ endif
+
+ ifeq ($(USE_LIBNL20),1)
+CFLAGS += DCONFIG_LIBNL20
+NLLIBS = -lnl-genl -lnl-2.0
+ else
+NLLIBS = -lnl
+ endif
+
+endif
+
 ifeq ($(V),1)
 Q=
 NQ=@true
@@ -111,6 +139,10 @@ verify: $(REG_BIN) regdbdump
 	@$(NQ) ' GZIP' $<
 	$(Q)gzip < $< > $@
 
+install-reg:
+	git clone $(REG_GIT) wireless-regdb
+	$(INSTALL) -m 0444 -D wireless-regdb/regulatory.bin $(REG_BIN)
+
 install: crda crda.8.gz regdbdump.8.gz
 	$(NQ) '  INSTALL  crda'
 	$(Q)$(MKDIR) $(DESTDIR)/$(SBINDIR)

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CRDA and cross-compilation
  2009-08-06  8:08 CRDA and cross-compilation Philip A. Prindeville
@ 2009-08-06 14:46 ` Jon Loeliger
  2009-08-06 16:41   ` Pavel Roskin
  2009-08-06 15:09 ` John W. Linville
  1 sibling, 1 reply; 22+ messages in thread
From: Jon Loeliger @ 2009-08-06 14:46 UTC (permalink / raw)
  To: Philip A. Prindeville; +Cc: linux-wireless

On Thu, 2009-08-06 at 01:08 -0700, Philip A. Prindeville wrote:
> Who currently owns CRDA?
> 
> I started to stare at cross-compiling issues, but realized that we need
> two versions of reglib.o and print-regdom.o...
> 
> One to link with regdumpdb (compiled with HOSTCC) and one to link with
> everything else (compiled with TARGET_CC)...
> 
> No easy way to do this without a lot of changes.

I posted a 5-part patch series to address this issue.
To the best of my knowledge, it has not been applied yet.

You can find it here:

http://article.gmane.org/gmane.linux.kernel.wireless.general/35350

HTH,
jdl



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CRDA and cross-compilation
  2009-08-06  8:08 CRDA and cross-compilation Philip A. Prindeville
  2009-08-06 14:46 ` Jon Loeliger
@ 2009-08-06 15:09 ` John W. Linville
  1 sibling, 0 replies; 22+ messages in thread
From: John W. Linville @ 2009-08-06 15:09 UTC (permalink / raw)
  To: Philip A. Prindeville; +Cc: linux-wireless, Luis R. Rodriguez, Luis Rodriguez

On Thu, Aug 06, 2009 at 01:08:30AM -0700, Philip A. Prindeville wrote:
> Who currently owns CRDA?

Luis Rodriguez <mcgrof@gmail.com>
Luis R. Rodriguez <lrodriguez@atheros.com>

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.
			¡Viva Honduras Libre!

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CRDA and cross-compilation
  2009-08-06 14:46 ` Jon Loeliger
@ 2009-08-06 16:41   ` Pavel Roskin
  2009-08-06 16:56     ` Luis R. Rodriguez
  0 siblings, 1 reply; 22+ messages in thread
From: Pavel Roskin @ 2009-08-06 16:41 UTC (permalink / raw)
  To: Jon Loeliger; +Cc: Philip A. Prindeville, linux-wireless

On Thu, 2009-08-06 at 09:46 -0500, Jon Loeliger wrote:
> On Thu, 2009-08-06 at 01:08 -0700, Philip A. Prindeville wrote:
> > Who currently owns CRDA?
> > 
> > I started to stare at cross-compiling issues, but realized that we need
> > two versions of reglib.o and print-regdom.o...
> > 
> > One to link with regdumpdb (compiled with HOSTCC) and one to link with
> > everything else (compiled with TARGET_CC)...
> > 
> > No easy way to do this without a lot of changes.
> 
> I posted a 5-part patch series to address this issue.
> To the best of my knowledge, it has not been applied yet.
> 
> You can find it here:
> 
> http://article.gmane.org/gmane.linux.kernel.wireless.general/35350

I objected against using the misleading use of the "TARGET" work in some
variables, but there was no reaction.  Failure to react to objections is
the likely reason it wasn't applied.

I also think that you add too much complexity to the Makefile.

Also, the use of .config is not common.  Most valuables can be specified
on the command line.  That would override the definitions in Makefile,
and that's how it's done.

For instance, you can have this in Makefile:

HOSTCC = gcc
CC = $(HOSTCC)

Running "make CC=/opt/mips/bin/gcc" would override CC but not HOSTCC.

-- 
Regards,
Pavel Roskin

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CRDA and cross-compilation
  2009-08-06 16:41   ` Pavel Roskin
@ 2009-08-06 16:56     ` Luis R. Rodriguez
  2009-08-06 17:38       ` Philip A. Prindeville
  2009-08-06 17:45       ` Pavel Roskin
  0 siblings, 2 replies; 22+ messages in thread
From: Luis R. Rodriguez @ 2009-08-06 16:56 UTC (permalink / raw)
  To: Pavel Roskin; +Cc: Jon Loeliger, Philip A. Prindeville, linux-wireless

On Thu, Aug 6, 2009 at 9:41 AM, Pavel Roskin<proski@gnu.org> wrote:
> On Thu, 2009-08-06 at 09:46 -0500, Jon Loeliger wrote:
>> On Thu, 2009-08-06 at 01:08 -0700, Philip A. Prindeville wrote:
>> > Who currently owns CRDA?
>> >
>> > I started to stare at cross-compiling issues, but realized that we need
>> > two versions of reglib.o and print-regdom.o...
>> >
>> > One to link with regdumpdb (compiled with HOSTCC) and one to link with
>> > everything else (compiled with TARGET_CC)...
>> >
>> > No easy way to do this without a lot of changes.
>>
>> I posted a 5-part patch series to address this issue.
>> To the best of my knowledge, it has not been applied yet.
>>
>> You can find it here:
>>
>> http://article.gmane.org/gmane.linux.kernel.wireless.general/35350
>
> I objected against using the misleading use of the "TARGET" work in some
> variables, but there was no reaction.  Failure to react to objections is
> the likely reason it wasn't applied.

Indeed.

> I also think that you add too much complexity to the Makefile.

Agreed.

> Also, the use of .config is not common.  Most valuables can be specified
> on the command line.  That would override the definitions in Makefile,
> and that's how it's done.

Yeah for something so simple as CRDA it seems overkill to have a .config.

> For instance, you can have this in Makefile:
>
> HOSTCC = gcc
> CC = $(HOSTCC)
>
> Running "make CC=/opt/mips/bin/gcc" would override CC but not HOSTCC.

ACK, is it possible to make it simpler?

  Luis

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CRDA and cross-compilation
  2009-08-06 16:56     ` Luis R. Rodriguez
@ 2009-08-06 17:38       ` Philip A. Prindeville
  2009-08-06 17:45       ` Pavel Roskin
  1 sibling, 0 replies; 22+ messages in thread
From: Philip A. Prindeville @ 2009-08-06 17:38 UTC (permalink / raw)
  To: Luis R. Rodriguez; +Cc: Pavel Roskin, Jon Loeliger, linux-wireless

Luis R. Rodriguez wrote:
> On Thu, Aug 6, 2009 at 9:41 AM, Pavel Roskin<proski@gnu.org> wrote:
>> On Thu, 2009-08-06 at 09:46 -0500, Jon Loeliger wrote:
>>> On Thu, 2009-08-06 at 01:08 -0700, Philip A. Prindeville wrote:
>>>> Who currently owns CRDA?
>>>>
>>>> I started to stare at cross-compiling issues, but realized that we need
>>>> two versions of reglib.o and print-regdom.o...
>>>>
>>>> One to link with regdumpdb (compiled with HOSTCC) and one to link with
>>>> everything else (compiled with TARGET_CC)...
>>>>
>>>> No easy way to do this without a lot of changes.
>>> I posted a 5-part patch series to address this issue.
>>> To the best of my knowledge, it has not been applied yet.
>>>
>>> You can find it here:
>>>
>>> http://article.gmane.org/gmane.linux.kernel.wireless.general/35350
>> I objected against using the misleading use of the "TARGET" work in some
>> variables, but there was no reaction.  Failure to react to objections is
>> the likely reason it wasn't applied.
> 
> Indeed.
> 
>> I also think that you add too much complexity to the Makefile.
> 
> Agreed.
> 
>> Also, the use of .config is not common.  Most valuables can be specified
>> on the command line.  That would override the definitions in Makefile,
>> and that's how it's done.
> 
> Yeah for something so simple as CRDA it seems overkill to have a .config.
> 
>> For instance, you can have this in Makefile:
>>
>> HOSTCC = gcc
>> CC = $(HOSTCC)
>>
>> Running "make CC=/opt/mips/bin/gcc" would override CC but not HOSTCC.
> 
> ACK, is it possible to make it simpler?
> 
>   Luis

You could also have:

-include .config

HOSTCC ?= gcc
...

and that will only set (default) the unset variables...

-Philip


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CRDA and cross-compilation
  2009-08-06 16:56     ` Luis R. Rodriguez
  2009-08-06 17:38       ` Philip A. Prindeville
@ 2009-08-06 17:45       ` Pavel Roskin
  2009-08-06 18:30         ` Philip A. Prindeville
                           ` (2 more replies)
  1 sibling, 3 replies; 22+ messages in thread
From: Pavel Roskin @ 2009-08-06 17:45 UTC (permalink / raw)
  To: Luis R. Rodriguez; +Cc: Jon Loeliger, Philip A. Prindeville, linux-wireless

On Thu, 2009-08-06 at 09:56 -0700, Luis R. Rodriguez wrote:

> ACK, is it possible to make it simpler?

OK, here's my take.

We only need a native compiler to verify regulatory.bin.  I believe it's
orthogonal to building CRDA.

For someone doing a cross-compilation, it makes no sense to verify the
installed regulatory.bin.  Thus, the verification should be optional.

But the compilation of regdbdump shouldn't be.  Firstly, it's installed
by "make install".  Secondly, somebody may want to verify regulatory.bin
on the target system.

Here's the patch:


crda: make it possible to disable verification

Signed-off-by: Pavel Roskin <proski@gnu.org>
---
 Makefile |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index b93b735..3cc61c2 100644
--- a/Makefile
+++ b/Makefile
@@ -24,7 +24,9 @@ PUBKEY_DIR?=pubkeys
 
 CFLAGS += -Wall -g
 
-all: $(REG_BIN) crda intersect verify
+all: all_noverify verify
+
+all_noverify: crda intersect regdbdump
 
 ifeq ($(USE_OPENSSL),1)
 CFLAGS += -DUSE_OPENSSL `pkg-config --cflags openssl`
@@ -74,11 +76,12 @@ $(REG_BIN):
 	$(NQ) '  EXIST ' $(REG_BIN)
 	$(NQ)
 	$(NQ) ERROR: The file: $(REG_BIN) is missing. You need this in place in order
-	$(NQ) to build CRDA. You can get it from:
+	$(NQ) to verify CRDA. You can get it from:
 	$(NQ)
 	$(NQ) $(REG_GIT)
 	$(NQ)
 	$(NQ) "Once cloned (no need to build) cp regulatory.bin to $(REG_BIN)"
+	$(NQ) "Use \"make noverify\" to disable verification"
 	$(NQ)
 	$(Q) exit 1
 

-- 
Regards,
Pavel Roskin

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* Re: CRDA and cross-compilation
  2009-08-06 17:45       ` Pavel Roskin
@ 2009-08-06 18:30         ` Philip A. Prindeville
  2009-08-06 18:41           ` Pavel Roskin
  2009-08-06 18:42         ` Luis R. Rodriguez
  2009-08-06 19:14         ` Philip A. Prindeville
  2 siblings, 1 reply; 22+ messages in thread
From: Philip A. Prindeville @ 2009-08-06 18:30 UTC (permalink / raw)
  To: Pavel Roskin; +Cc: Luis R. Rodriguez, Jon Loeliger, linux-wireless


Pavel Roskin wrote:
> On Thu, 2009-08-06 at 09:56 -0700, Luis R. Rodriguez wrote:
> 
>> ACK, is it possible to make it simpler?
> 
> OK, here's my take.
> 
> We only need a native compiler to verify regulatory.bin.  I believe it's
> orthogonal to building CRDA.
> 
> For someone doing a cross-compilation, it makes no sense to verify the
> installed regulatory.bin.  Thus, the verification should be optional.
> 
> But the compilation of regdbdump shouldn't be.  Firstly, it's installed
> by "make install".  Secondly, somebody may want to verify regulatory.bin
> on the target system.
> 
> Here's the patch:
> 
[snip]

Dumb question but, why not just build a target and host version each of regdumpdb?

-Philip

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CRDA and cross-compilation
  2009-08-06 18:30         ` Philip A. Prindeville
@ 2009-08-06 18:41           ` Pavel Roskin
  0 siblings, 0 replies; 22+ messages in thread
From: Pavel Roskin @ 2009-08-06 18:41 UTC (permalink / raw)
  To: Philip A. Prindeville; +Cc: Luis R. Rodriguez, Jon Loeliger, linux-wireless

On Thu, 2009-08-06 at 11:30 -0700, Philip A. Prindeville wrote:

> Dumb question but, why not just build a target and host version each of regdumpdb?

Because it's more complicated.  Because we may want to disable
verification for reasons other than cross-compiling.  Because it's
already possible:

set -e
make verify REG_BIN=/targetfs/regulatory.bin
make clean
make all_noverify CC=cross-gcc

-- 
Regards,
Pavel Roskin

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CRDA and cross-compilation
  2009-08-06 17:45       ` Pavel Roskin
  2009-08-06 18:30         ` Philip A. Prindeville
@ 2009-08-06 18:42         ` Luis R. Rodriguez
  2009-08-06 19:08           ` Pavel Roskin
       [not found]           ` <4A7BD15E.1030604@redfish-solutions.com>
  2009-08-06 19:14         ` Philip A. Prindeville
  2 siblings, 2 replies; 22+ messages in thread
From: Luis R. Rodriguez @ 2009-08-06 18:42 UTC (permalink / raw)
  To: Pavel Roskin; +Cc: Jon Loeliger, Philip A. Prindeville, linux-wireless

On Thu, Aug 6, 2009 at 10:45 AM, Pavel Roskin<proski@gnu.org> wrote:
> On Thu, 2009-08-06 at 09:56 -0700, Luis R. Rodriguez wrote:
>
>> ACK, is it possible to make it simpler?
>
> OK, here's my take.
>
> We only need a native compiler to verify regulatory.bin.  I believe it's
> orthogonal to building CRDA.
>
> For someone doing a cross-compilation, it makes no sense to verify the
> installed regulatory.bin.  Thus, the verification should be optional.
>
> But the compilation of regdbdump shouldn't be.  Firstly, it's installed
> by "make install".  Secondly, somebody may want to verify regulatory.bin
> on the target system.
>
> Here's the patch:
>
>
> crda: make it possible to disable verification
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
> ---
>  Makefile |    7 +++++--
>  1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index b93b735..3cc61c2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -24,7 +24,9 @@ PUBKEY_DIR?=pubkeys
>
>  CFLAGS += -Wall -g
>
> -all: $(REG_BIN) crda intersect verify
> +all: all_noverify verify
> +
> +all_noverify: crda intersect regdbdump

You removed REG_BIN from here, was that intentional?

>  ifeq ($(USE_OPENSSL),1)
>  CFLAGS += -DUSE_OPENSSL `pkg-config --cflags openssl`
> @@ -74,11 +76,12 @@ $(REG_BIN):
>        $(NQ) '  EXIST ' $(REG_BIN)
>        $(NQ)
>        $(NQ) ERROR: The file: $(REG_BIN) is missing. You need this in place in order
> -       $(NQ) to build CRDA. You can get it from:
> +       $(NQ) to verify CRDA. You can get it from:
>        $(NQ)
>        $(NQ) $(REG_GIT)
>        $(NQ)
>        $(NQ) "Once cloned (no need to build) cp regulatory.bin to $(REG_BIN)"
> +       $(NQ) "Use \"make noverify\" to disable verification"
>        $(NQ)
>        $(Q) exit 1
>
>
> --
> Regards,
> Pavel Roskin
>

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CRDA and cross-compilation
  2009-08-06 18:42         ` Luis R. Rodriguez
@ 2009-08-06 19:08           ` Pavel Roskin
  2009-08-06 19:23             ` Luis R. Rodriguez
       [not found]           ` <4A7BD15E.1030604@redfish-solutions.com>
  1 sibling, 1 reply; 22+ messages in thread
From: Pavel Roskin @ 2009-08-06 19:08 UTC (permalink / raw)
  To: Luis R. Rodriguez; +Cc: Jon Loeliger, Philip A. Prindeville, linux-wireless

On Thu, 2009-08-06 at 11:42 -0700, Luis R. Rodriguez wrote:

> > -all: $(REG_BIN) crda intersect verify
> > +all: all_noverify verify
> > +
> > +all_noverify: crda intersect regdbdump
> 
> You removed REG_BIN from here, was that intentional?

Yes.  It's not needed for the build.  As for the "verify" target, it
already depends on $(REG_BIN)

-- 
Regards,
Pavel Roskin

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CRDA and cross-compilation
  2009-08-06 17:45       ` Pavel Roskin
  2009-08-06 18:30         ` Philip A. Prindeville
  2009-08-06 18:42         ` Luis R. Rodriguez
@ 2009-08-06 19:14         ` Philip A. Prindeville
  2009-08-06 19:21           ` Jon Loeliger
  2 siblings, 1 reply; 22+ messages in thread
From: Philip A. Prindeville @ 2009-08-06 19:14 UTC (permalink / raw)
  To: Pavel Roskin; +Cc: Luis R. Rodriguez, Jon Loeliger, linux-wireless

Pavel Roskin wrote:
> On Thu, 2009-08-06 at 09:56 -0700, Luis R. Rodriguez wrote:
> 
>> ACK, is it possible to make it simpler?
> 
> OK, here's my take.
> 
> We only need a native compiler to verify regulatory.bin.  I believe it's
> orthogonal to building CRDA.
> 
> For someone doing a cross-compilation, it makes no sense to verify the
> installed regulatory.bin.  Thus, the verification should be optional.
> 
> But the compilation of regdbdump shouldn't be.  Firstly, it's installed
> by "make install".  Secondly, somebody may want to verify regulatory.bin
> on the target system.
> 
> Here's the patch:
> 
> 
> crda: make it possible to disable verification
> 
> Signed-off-by: Pavel Roskin <proski@gnu.org>
> ---
>  Makefile |    7 +++++--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index b93b735..3cc61c2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -24,7 +24,9 @@ PUBKEY_DIR?=pubkeys
>  
>  CFLAGS += -Wall -g
>  
> -all: $(REG_BIN) crda intersect verify
> +all: all_noverify verify
> +
> +all_noverify: crda intersect regdbdump
>  
>  ifeq ($(USE_OPENSSL),1)
>  CFLAGS += -DUSE_OPENSSL `pkg-config --cflags openssl`
> @@ -74,11 +76,12 @@ $(REG_BIN):
>  	$(NQ) '  EXIST ' $(REG_BIN)
>  	$(NQ)
>  	$(NQ) ERROR: The file: $(REG_BIN) is missing. You need this in place in order
> -	$(NQ) to build CRDA. You can get it from:
> +	$(NQ) to verify CRDA. You can get it from:
>  	$(NQ)
>  	$(NQ) $(REG_GIT)
>  	$(NQ)
>  	$(NQ) "Once cloned (no need to build) cp regulatory.bin to $(REG_BIN)"
> +	$(NQ) "Use \"make noverify\" to disable verification"
>  	$(NQ)
>  	$(Q) exit 1
>  
> 

Can someone roll *all* the patches together?  For instance, "pkg-config" shouldn't be used on a cross-compile...

-Philip


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CRDA and cross-compilation
  2009-08-06 19:14         ` Philip A. Prindeville
@ 2009-08-06 19:21           ` Jon Loeliger
  0 siblings, 0 replies; 22+ messages in thread
From: Jon Loeliger @ 2009-08-06 19:21 UTC (permalink / raw)
  To: Philip A. Prindeville; +Cc: Pavel Roskin, Luis R. Rodriguez, linux-wireless

On Thu, 2009-08-06 at 12:14 -0700, Philip A. Prindeville wrote:

> 
> Can someone roll *all* the patches together?  For instance, "pkg-config" shouldn't be used on a cross-compile...
> 
> -Philip


Philip,

These are the sorts of issues that made my patch seem
more complicated than first blush might suggest was needed.

jdl



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CRDA and cross-compilation
  2009-08-06 19:08           ` Pavel Roskin
@ 2009-08-06 19:23             ` Luis R. Rodriguez
  0 siblings, 0 replies; 22+ messages in thread
From: Luis R. Rodriguez @ 2009-08-06 19:23 UTC (permalink / raw)
  To: Pavel Roskin; +Cc: Jon Loeliger, Philip A. Prindeville, linux-wireless

On Thu, Aug 6, 2009 at 12:08 PM, Pavel Roskin<proski@gnu.org> wrote:
> On Thu, 2009-08-06 at 11:42 -0700, Luis R. Rodriguez wrote:
>
>> > -all: $(REG_BIN) crda intersect verify
>> > +all: all_noverify verify
>> > +
>> > +all_noverify: crda intersect regdbdump
>>
>> You removed REG_BIN from here, was that intentional?
>
> Yes.  It's not needed for the build.  As for the "verify" target, it
> already depends on $(REG_BIN)

Oh nice, thanks applied!

  Luis

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH] CRDA and cross-compilation
       [not found]                 ` <1249698462.25983.7.camel@mj>
@ 2009-08-10 22:13                   ` Philip A. Prindeville
  2009-08-10 22:30                     ` Luis R. Rodriguez
  2009-08-11  0:41                     ` Philip Craig
  0 siblings, 2 replies; 22+ messages in thread
From: Philip A. Prindeville @ 2009-08-10 22:13 UTC (permalink / raw)
  To: Pavel Roskin; +Cc: Luis R. Rodriguez, Jon Loeliger, wireless

[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]

Pavel Roskin wrote:
> On Fri, 2009-08-07 at 17:09 -0700, Philip A. Prindeville wrote:
>> Luis R. Rodriguez wrote:
>>> Please send white space changes first in one patch, ie, that do not
>>> change anything other than that. Then send the other stuff.
>>>
>>>   Luis
>> Here it is.
> ...
>> -else
>> + else
> ...
>> +install-rb: wireless-regdb/regulatory.bin
> 
> If you don't understand what you were asked to do, I'll appreciate if
> you stop wasting everybody's time.
> 
> Nobody is going to extract useful bits from the patches you send,
> especially if you don't provide an adequate description of the changes.
> 
> I was able to cross-compile CDRA for MIPS without any changes other than
> those that have already been applied.

Since we compile a variety of images that are both Linux and i586 based as are the target and host, detecting instances amongst the 180+ packages contained in our distribution where the build used host parameters instead of target parameters can be painful and tedious.

Sometimes it's just best to isolate such code paths with a safe, obvious gating variable.  That's what I've tried to do here.

We don't just build images, we also make the entire SVN tree available to others to build in their environments as well (Fedora, Centos, Gentoo, Debian, x86, PPC, x86_64, etc).  We can't possibly test for every scenario our users will encounter, so we make things as safe as we know how.

Yes, I'm sure Pavel *was* able to build for his MIPS target in his environment.  That's a bet I can't make for all of our users, however, without these changes.

I've split our changes into two functional groups:

* allowing a cross-compilation without contamination by the host's own state via pkg-config bleeding into it.

* allowing regulatory.bin to be installed via an external Makefile without having to extract internal values from crda/Makefile (i.e. REG_BIN and REG_GIT).

These patches assume that Pavel's own "noverify" patch has already been applied.

[-- Attachment #2: crda-cross-compile.patch --]
[-- Type: text/plain, Size: 2845 bytes --]

Changes:

1. Remove trailing slashes from directory variables: they're redundant and cause duplicates if they are appended to a path that's already absolute.

2. Move invariant definitions to before any cross-compilation conditional sections for clarity (and to avoid having to duplicate them).

3. Bracket any host (native) compilation sections with conditional based on $(CROSS_COMPILE) being empty.

4. Add 'else' section for cross-compilation using openssl and libnl-1 (or libnl-2 if explicitly selected).


--- crda-1.1.0/Makefile	2009-08-10 13:37:36.000000000 -0700
+++ crda-1.1.0/Makefile.new	2009-08-10 13:37:11.000000000 -0700
@@ -3,10 +3,10 @@
 REG_BIN?=/usr/lib/crda/regulatory.bin
 REG_GIT?=git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-regdb.git
 
-PREFIX ?= /usr/
-MANDIR ?= $(PREFIX)/share/man/
+PREFIX ?= /usr
+MANDIR ?= $(PREFIX)/share/man
 
-SBINDIR ?= /sbin/
+SBINDIR ?= /sbin
 
 # Use a custom CRDA_UDEV_LEVEL when callling make install to
 # change your desired level for the udev regulatory.rules
@@ -14,7 +14,7 @@
 UDEV_LEVEL=$(CRDA_UDEV_LEVEL)-
 # You can customize this if your distributions uses
 # a different location.
-UDEV_RULE_DIR?=/lib/udev/rules.d/
+UDEV_RULE_DIR?=/lib/udev/rules.d
 
 # If your distribution requires a custom pubkeys dir
 # you must update this variable to reflect where the
@@ -22,48 +22,76 @@
 # with make PUBKEY_DIR=/usr/lib/crda/pubkeys
 PUBKEY_DIR?=pubkeys
 
+MKDIR ?= mkdir -p
+INSTALL ?= install
+
 CFLAGS += -Wall -g
 
 all: all_noverify verify
 
 all_noverify: crda intersect regdbdump
 
-ifeq ($(USE_OPENSSL),1)
+ifeq ($(CROSS_COMPILE),)
+
+ ifeq ($(USE_OPENSSL),1)
 CFLAGS += -DUSE_OPENSSL `pkg-config --cflags openssl`
 LDLIBS += `pkg-config --libs openssl`
 
 reglib.o: keys-ssl.c
 
-else
+ else
 CFLAGS += -DUSE_GCRYPT
 LDLIBS += -lgcrypt
 
 reglib.o: keys-gcrypt.c
 
-endif
-MKDIR ?= mkdir -p
-INSTALL ?= install
+ endif
 
 NL1FOUND := $(shell pkg-config --atleast-version=1 libnl-1 && echo Y)
 NL2FOUND := $(shell pkg-config --atleast-version=2 libnl-2.0 && echo Y)
 
-ifeq ($(NL1FOUND),Y)
+ ifeq ($(NL1FOUND),Y)
 NLLIBNAME = libnl-1
-endif
+ endif
 
-ifeq ($(NL2FOUND),Y)
+ ifeq ($(NL2FOUND),Y)
 CFLAGS += -DCONFIG_LIBNL20
 NLLIBS += -lnl-genl
 NLLIBNAME = libnl-2.0
-endif
+ endif
 
-ifeq ($(NLLIBNAME),)
+ ifeq ($(NLLIBNAME),)
 $(error Cannot find development files for any supported version of libnl)
-endif
+ endif
 
 NLLIBS += `pkg-config --libs $(NLLIBNAME)`
 CFLAGS += `pkg-config --cflags $(NLLIBNAME)`
 
+else
+
+ ifeq ($(USE_OPENSSL),1)
+CFLAGS += -DUSE_OPENSSL
+LDLIBS += -lssl
+
+reglib.o: keys-ssl.c
+
+ else
+CFLAGS += -DUSE_GCRYPT
+LDLIBS += -lgcrypt
+
+reglib.o: keys-gcrypt.c
+
+ endif
+
+ ifeq ($(USE_LIBNL20),1)
+CFLAGS += -DCONFIG_LIBNL20
+NLLIBS = -lnl-genl -lnl-2.0
+ else
+NLLIBS = -lnl
+ endif
+
+endif
+
 ifeq ($(V),1)
 Q=
 NQ=@true


[-- Attachment #3: crda-regbin-install.patch --]
[-- Type: text/plain, Size: 971 bytes --]

Add a couple of rules to (1) download (via GIT) John's working copy of regulatory.bin and (2) install it in the appropriate target destination.  This avoids us having to parse the Makefile for REG_BIN and REG_GIT from an enclosing (nesting) makefile, as is common in distros and buildroot environments in particular.

--- crda-1.1.0/Makefile	2009-08-10 13:37:36.000000000 -0700
+++ crda-1.1.0/Makefile.new	2009-08-10 13:37:11.000000000 -0700
@@ -136,6 +164,14 @@
 	$(NQ) '  INSTALL  regdbdump.8.gz'
 	$(Q)$(INSTALL) -m 644 -t $(DESTDIR)/$(MANDIR)/man8/ regdbdump.8.gz
 
+install-rb: wireless-regdb/regulatory.bin
+	$(NQ) '  INSTALL  regulatory.bin'
+	$(Q)$(INSTALL) -m 444 -D wireless-regdb/regulatory.bin $(DESTDIR)/$(REG_BIN)
+
+wireless-regdb/regulatory.bin:
+	@rm -rf wireless-regdb
+	git clone -q $(REG_GIT) wireless-regdb
+
 clean:
 	$(Q)rm -f crda regdbdump intersect *.o *~ *.pyc keys-*.c *.gz \
 	udev/$(UDEV_LEVEL)regulatory.rules udev/regulatory.rules.parsed


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] CRDA and cross-compilation
  2009-08-10 22:13                   ` [PATCH] " Philip A. Prindeville
@ 2009-08-10 22:30                     ` Luis R. Rodriguez
  2009-08-10 23:55                       ` Philip A. Prindeville
  2009-08-11  0:41                     ` Philip Craig
  1 sibling, 1 reply; 22+ messages in thread
From: Luis R. Rodriguez @ 2009-08-10 22:30 UTC (permalink / raw)
  To: Philip A. Prindeville; +Cc: Pavel Roskin, Jon Loeliger, wireless

On Mon, Aug 10, 2009 at 3:13 PM, Philip A.
Prindeville<philipp_subx@redfish-solutions.com> wrote:
> Pavel Roskin wrote:
>> On Fri, 2009-08-07 at 17:09 -0700, Philip A. Prindeville wrote:
>>> Luis R. Rodriguez wrote:
>>>> Please send white space changes first in one patch, ie, that do not
>>>> change anything other than that. Then send the other stuff.
>>>>
>>>>   Luis
>>> Here it is.
>> ...
>>> -else
>>> + else
>> ...
>>> +install-rb: wireless-regdb/regulatory.bin
>>
>> If you don't understand what you were asked to do, I'll appreciate if
>> you stop wasting everybody's time.
>>
>> Nobody is going to extract useful bits from the patches you send,
>> especially if you don't provide an adequate description of the changes.
>>
>> I was able to cross-compile CDRA for MIPS without any changes other than
>> those that have already been applied.
>
> Since we compile a variety of images that are both Linux and i586 based as are the target and host, detecting instances amongst the 180+ packages contained in our distribution where the build used host parameters instead of target parameters can be painful and tedious.
>
> Sometimes it's just best to isolate such code paths with a safe, obvious gating variable.  That's what I've tried to do here.
>
> We don't just build images, we also make the entire SVN tree available to others to build in their environments as well (Fedora, Centos, Gentoo, Debian, x86, PPC, x86_64, etc).  We can't possibly test for every scenario our users will encounter, so we make things as safe as we know how.
>
> Yes, I'm sure Pavel *was* able to build for his MIPS target in his environment.  That's a bet I can't make for all of our users, however, without these changes.
>
> I've split our changes into two functional groups:
>
> * allowing a cross-compilation without contamination by the host's own state via pkg-config bleeding into it.
>
> * allowing regulatory.bin to be installed via an external Makefile without having to extract internal values from crda/Makefile (i.e. REG_BIN and REG_GIT).
>
> These patches assume that Pavel's own "noverify" patch has already been applied.
>
> Changes:
>
> 1. Remove trailing slashes from directory variables: they're redundant and cause duplicates if they are appended to a path that's already absolute.
>
> 2. Move invariant definitions to before any cross-compilation conditional sections for clarity (and to avoid having to duplicate them).
>
> 3. Bracket any host (native) compilation sections with conditional based on $(CROSS_COMPILE) being empty.
>
> 4. Add 'else' section for cross-compilation using openssl and libnl-1 (or libnl-2 if explicitly selected).
>
>
> --- crda-1.1.0/Makefile 2009-08-10 13:37:36.000000000 -0700
> +++ crda-1.1.0/Makefile.new     2009-08-10 13:37:11.000000000 -0700
> @@ -3,10 +3,10 @@
>  REG_BIN?=/usr/lib/crda/regulatory.bin
>  REG_GIT?=git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-regdb.git
>
> -PREFIX ?= /usr/
> -MANDIR ?= $(PREFIX)/share/man/
> +PREFIX ?= /usr
> +MANDIR ?= $(PREFIX)/share/man
>
> -SBINDIR ?= /sbin/
> +SBINDIR ?= /sbin
>
>  # Use a custom CRDA_UDEV_LEVEL when callling make install to
>  # change your desired level for the udev regulatory.rules
> @@ -14,7 +14,7 @@
>  UDEV_LEVEL=$(CRDA_UDEV_LEVEL)-
>  # You can customize this if your distributions uses
>  # a different location.
> -UDEV_RULE_DIR?=/lib/udev/rules.d/
> +UDEV_RULE_DIR?=/lib/udev/rules.d
>
>  # If your distribution requires a custom pubkeys dir
>  # you must update this variable to reflect where the
> @@ -22,48 +22,76 @@
>  # with make PUBKEY_DIR=/usr/lib/crda/pubkeys
>  PUBKEY_DIR?=pubkeys
>
> +MKDIR ?= mkdir -p
> +INSTALL ?= install
> +
>  CFLAGS += -Wall -g
>
>  all: all_noverify verify
>
>  all_noverify: crda intersect regdbdump
>
> -ifeq ($(USE_OPENSSL),1)
> +ifeq ($(CROSS_COMPILE),)
> +
> + ifeq ($(USE_OPENSSL),1)
>  CFLAGS += -DUSE_OPENSSL `pkg-config --cflags openssl`
>  LDLIBS += `pkg-config --libs openssl`
>
>  reglib.o: keys-ssl.c
>
> -else
> + else
>  CFLAGS += -DUSE_GCRYPT
>  LDLIBS += -lgcrypt
>
>  reglib.o: keys-gcrypt.c
>
> -endif
> -MKDIR ?= mkdir -p
> -INSTALL ?= install
> + endif
>
>  NL1FOUND := $(shell pkg-config --atleast-version=1 libnl-1 && echo Y)
>  NL2FOUND := $(shell pkg-config --atleast-version=2 libnl-2.0 && echo Y)
>
> -ifeq ($(NL1FOUND),Y)
> + ifeq ($(NL1FOUND),Y)
>  NLLIBNAME = libnl-1
> -endif
> + endif
>
> -ifeq ($(NL2FOUND),Y)
> + ifeq ($(NL2FOUND),Y)
>  CFLAGS += -DCONFIG_LIBNL20
>  NLLIBS += -lnl-genl
>  NLLIBNAME = libnl-2.0
> -endif
> + endif
>
> -ifeq ($(NLLIBNAME),)
> + ifeq ($(NLLIBNAME),)
>  $(error Cannot find development files for any supported version of libnl)
> -endif
> + endif
>
>  NLLIBS += `pkg-config --libs $(NLLIBNAME)`
>  CFLAGS += `pkg-config --cflags $(NLLIBNAME)`
>
> +else
> +
> + ifeq ($(USE_OPENSSL),1)
> +CFLAGS += -DUSE_OPENSSL
> +LDLIBS += -lssl
> +
> +reglib.o: keys-ssl.c
> +
> + else
> +CFLAGS += -DUSE_GCRYPT
> +LDLIBS += -lgcrypt
> +
> +reglib.o: keys-gcrypt.c
> +
> + endif
> +
> + ifeq ($(USE_LIBNL20),1)
> +CFLAGS += -DCONFIG_LIBNL20
> +NLLIBS = -lnl-genl -lnl-2.0
> + else
> +NLLIBS = -lnl
> + endif
> +
> +endif
> +
>  ifeq ($(V),1)
>  Q=
>  NQ=@true
>
>
> Add a couple of rules to (1) download (via GIT) John's working copy of regulatory.bin and (2) install it in the appropriate target destination.  This avoids us having to parse the Makefile for REG_BIN and REG_GIT from an enclosing (nesting) makefile, as is common in distros and buildroot environments in particular.
>
> --- crda-1.1.0/Makefile 2009-08-10 13:37:36.000000000 -0700
> +++ crda-1.1.0/Makefile.new     2009-08-10 13:37:11.000000000 -0700
> @@ -136,6 +164,14 @@
>        $(NQ) '  INSTALL  regdbdump.8.gz'
>        $(Q)$(INSTALL) -m 644 -t $(DESTDIR)/$(MANDIR)/man8/ regdbdump.8.gz
>
> +install-rb: wireless-regdb/regulatory.bin
> +       $(NQ) '  INSTALL  regulatory.bin'
> +       $(Q)$(INSTALL) -m 444 -D wireless-regdb/regulatory.bin $(DESTDIR)/$(REG_BIN)
> +
> +wireless-regdb/regulatory.bin:
> +       @rm -rf wireless-regdb
> +       git clone -q $(REG_GIT) wireless-regdb
> +
>  clean:
>        $(Q)rm -f crda regdbdump intersect *.o *~ *.pyc keys-*.c *.gz \
>        udev/$(UDEV_LEVEL)regulatory.rules udev/regulatory.rules.parsed

This is a glory mess, please stop trying.

  Luis

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] CRDA and cross-compilation
  2009-08-10 22:30                     ` Luis R. Rodriguez
@ 2009-08-10 23:55                       ` Philip A. Prindeville
  2009-08-11  0:25                         ` Pavel Roskin
  0 siblings, 1 reply; 22+ messages in thread
From: Philip A. Prindeville @ 2009-08-10 23:55 UTC (permalink / raw)
  To: Luis R. Rodriguez; +Cc: Pavel Roskin, Jon Loeliger, wireless

Luis R. Rodriguez wrote:
> On Mon, Aug 10, 2009 at 3:13 PM, Philip A.
> Prindeville<philipp_subx@redfish-solutions.com> wrote:
>> Pavel Roskin wrote:
>>> On Fri, 2009-08-07 at 17:09 -0700, Philip A. Prindeville wrote:
>>>> Luis R. Rodriguez wrote:
>>>>> Please send white space changes first in one patch, ie, that do not
>>>>> change anything other than that. Then send the other stuff.
>>>>>
>>>>>   Luis
>>>> Here it is.
>>> ...
>>>> -else
>>>> + else
>>> ...
>>>> +install-rb: wireless-regdb/regulatory.bin
>>> If you don't understand what you were asked to do, I'll appreciate if
>>> you stop wasting everybody's time.
>>>
>>> Nobody is going to extract useful bits from the patches you send,
>>> especially if you don't provide an adequate description of the changes.
>>>
>>> I was able to cross-compile CDRA for MIPS without any changes other than
>>> those that have already been applied.
>> Since we compile a variety of images that are both Linux and i586 based as are the target and host, detecting instances amongst the 180+ packages contained in our distribution where the build used host parameters instead of target parameters can be painful and tedious.
>>
>> Sometimes it's just best to isolate such code paths with a safe, obvious gating variable.  That's what I've tried to do here.
>>
>> We don't just build images, we also make the entire SVN tree available to others to build in their environments as well (Fedora, Centos, Gentoo, Debian, x86, PPC, x86_64, etc).  We can't possibly test for every scenario our users will encounter, so we make things as safe as we know how.
>>
>> Yes, I'm sure Pavel *was* able to build for his MIPS target in his environment.  That's a bet I can't make for all of our users, however, without these changes.
>>
>> I've split our changes into two functional groups:
>>
>> * allowing a cross-compilation without contamination by the host's own state via pkg-config bleeding into it.
>>
>> * allowing regulatory.bin to be installed via an external Makefile without having to extract internal values from crda/Makefile (i.e. REG_BIN and REG_GIT).
>>
>> These patches assume that Pavel's own "noverify" patch has already been applied.
>>
>> Changes:
>>
>> 1. Remove trailing slashes from directory variables: they're redundant and cause duplicates if they are appended to a path that's already absolute.
>>
>> 2. Move invariant definitions to before any cross-compilation conditional sections for clarity (and to avoid having to duplicate them).
>>
>> 3. Bracket any host (native) compilation sections with conditional based on $(CROSS_COMPILE) being empty.
>>
>> 4. Add 'else' section for cross-compilation using openssl and libnl-1 (or libnl-2 if explicitly selected).
>>
>>
>> --- crda-1.1.0/Makefile 2009-08-10 13:37:36.000000000 -0700
>> +++ crda-1.1.0/Makefile.new     2009-08-10 13:37:11.000000000 -0700
>> @@ -3,10 +3,10 @@
>>  REG_BIN?=/usr/lib/crda/regulatory.bin
>>  REG_GIT?=git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-regdb.git
>>
>> -PREFIX ?= /usr/
>> -MANDIR ?= $(PREFIX)/share/man/
>> +PREFIX ?= /usr
>> +MANDIR ?= $(PREFIX)/share/man
>>
>> -SBINDIR ?= /sbin/
>> +SBINDIR ?= /sbin
>>
>>  # Use a custom CRDA_UDEV_LEVEL when callling make install to
>>  # change your desired level for the udev regulatory.rules
>> @@ -14,7 +14,7 @@
>>  UDEV_LEVEL=$(CRDA_UDEV_LEVEL)-
>>  # You can customize this if your distributions uses
>>  # a different location.
>> -UDEV_RULE_DIR?=/lib/udev/rules.d/
>> +UDEV_RULE_DIR?=/lib/udev/rules.d
>>
>>  # If your distribution requires a custom pubkeys dir
>>  # you must update this variable to reflect where the
>> @@ -22,48 +22,76 @@
>>  # with make PUBKEY_DIR=/usr/lib/crda/pubkeys
>>  PUBKEY_DIR?=pubkeys
>>
>> +MKDIR ?= mkdir -p
>> +INSTALL ?= install
>> +
>>  CFLAGS += -Wall -g
>>
>>  all: all_noverify verify
>>
>>  all_noverify: crda intersect regdbdump
>>
>> -ifeq ($(USE_OPENSSL),1)
>> +ifeq ($(CROSS_COMPILE),)
>> +
>> + ifeq ($(USE_OPENSSL),1)
>>  CFLAGS += -DUSE_OPENSSL `pkg-config --cflags openssl`
>>  LDLIBS += `pkg-config --libs openssl`
>>
>>  reglib.o: keys-ssl.c
>>
>> -else
>> + else
>>  CFLAGS += -DUSE_GCRYPT
>>  LDLIBS += -lgcrypt
>>
>>  reglib.o: keys-gcrypt.c
>>
>> -endif
>> -MKDIR ?= mkdir -p
>> -INSTALL ?= install
>> + endif
>>
>>  NL1FOUND := $(shell pkg-config --atleast-version=1 libnl-1 && echo Y)
>>  NL2FOUND := $(shell pkg-config --atleast-version=2 libnl-2.0 && echo Y)
>>
>> -ifeq ($(NL1FOUND),Y)
>> + ifeq ($(NL1FOUND),Y)
>>  NLLIBNAME = libnl-1
>> -endif
>> + endif
>>
>> -ifeq ($(NL2FOUND),Y)
>> + ifeq ($(NL2FOUND),Y)
>>  CFLAGS += -DCONFIG_LIBNL20
>>  NLLIBS += -lnl-genl
>>  NLLIBNAME = libnl-2.0
>> -endif
>> + endif
>>
>> -ifeq ($(NLLIBNAME),)
>> + ifeq ($(NLLIBNAME),)
>>  $(error Cannot find development files for any supported version of libnl)
>> -endif
>> + endif
>>
>>  NLLIBS += `pkg-config --libs $(NLLIBNAME)`
>>  CFLAGS += `pkg-config --cflags $(NLLIBNAME)`
>>
>> +else
>> +
>> + ifeq ($(USE_OPENSSL),1)
>> +CFLAGS += -DUSE_OPENSSL
>> +LDLIBS += -lssl
>> +
>> +reglib.o: keys-ssl.c
>> +
>> + else
>> +CFLAGS += -DUSE_GCRYPT
>> +LDLIBS += -lgcrypt
>> +
>> +reglib.o: keys-gcrypt.c
>> +
>> + endif
>> +
>> + ifeq ($(USE_LIBNL20),1)
>> +CFLAGS += -DCONFIG_LIBNL20
>> +NLLIBS = -lnl-genl -lnl-2.0
>> + else
>> +NLLIBS = -lnl
>> + endif
>> +
>> +endif
>> +
>>  ifeq ($(V),1)
>>  Q=
>>  NQ=@true
>>
>>
>> Add a couple of rules to (1) download (via GIT) John's working copy of regulatory.bin and (2) install it in the appropriate target destination.  This avoids us having to parse the Makefile for REG_BIN and REG_GIT from an enclosing (nesting) makefile, as is common in distros and buildroot environments in particular.
>>
>> --- crda-1.1.0/Makefile 2009-08-10 13:37:36.000000000 -0700
>> +++ crda-1.1.0/Makefile.new     2009-08-10 13:37:11.000000000 -0700
>> @@ -136,6 +164,14 @@
>>        $(NQ) '  INSTALL  regdbdump.8.gz'
>>        $(Q)$(INSTALL) -m 644 -t $(DESTDIR)/$(MANDIR)/man8/ regdbdump.8.gz
>>
>> +install-rb: wireless-regdb/regulatory.bin
>> +       $(NQ) '  INSTALL  regulatory.bin'
>> +       $(Q)$(INSTALL) -m 444 -D wireless-regdb/regulatory.bin $(DESTDIR)/$(REG_BIN)
>> +
>> +wireless-regdb/regulatory.bin:
>> +       @rm -rf wireless-regdb
>> +       git clone -q $(REG_GIT) wireless-regdb
>> +
>>  clean:
>>        $(Q)rm -f crda regdbdump intersect *.o *~ *.pyc keys-*.c *.gz \
>>        udev/$(UDEV_LEVEL)regulatory.rules udev/regulatory.rules.parsed
> 
> This is a glory mess, please stop trying.
> 
>   Luis

You're right: that comment was much more helpful...  does it apply to the first file or the second or both?

And what in particular is a mess?

-Philip


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] CRDA and cross-compilation
  2009-08-10 23:55                       ` Philip A. Prindeville
@ 2009-08-11  0:25                         ` Pavel Roskin
  2009-08-11  0:41                           ` Philip A. Prindeville
  2009-08-11  5:52                           ` Philip A. Prindeville
  0 siblings, 2 replies; 22+ messages in thread
From: Pavel Roskin @ 2009-08-11  0:25 UTC (permalink / raw)
  To: Philip A. Prindeville; +Cc: Luis R. Rodriguez, Jon Loeliger, wireless

On Mon, 2009-08-10 at 16:55 -0700, Philip A. Prindeville wrote:

> You're right: that comment was much more helpful...  does it apply to the first file or the second or both?
> 
> And what in particular is a mess?

Cross compilation is not easy.  That's why there are such
"metadistros" (for the lack of a better word) as buildroot and
openembedded.  They have special entries for every package that specify
how to cross-compile it.  There are patches for many sources, although
it's better to have such files applied to the upstream sources.  But
it's inevitable that the build is influenced in some way to
cross-compile, often by specifying variables on the make command line.

I believe the developers of buildroot and openembedded would be able to
deal with CRDA as is.  If they find something that could be improved,
they can send a patch, but I don't think they will bother to change so
many things as your patch does.

Besides, it's one thing to follow sane rules that simplify
cross-compilation, such as providing the fourth argument to
AC_RUN_IFELSE in configure.ac or not using uname to determine the target
architecture.  It's another thing to support cross-compilation in a way
unique to the package.  The gain is miniscule, and the potential for
breaking is substantial.

Most importantly, you are wasting time of people who could be doing
something they are better at, such as development of wireless drivers.

There is no point in pushing the same patch over and over again, just
because you wrote it.  Please try to accept the fact that it's not
useful for others.  Maybe it was useful for you as an exercise.  But now
you are not helping.  Please move on and do something else.

-- 
Regards,
Pavel Roskin

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] CRDA and cross-compilation
  2009-08-10 22:13                   ` [PATCH] " Philip A. Prindeville
  2009-08-10 22:30                     ` Luis R. Rodriguez
@ 2009-08-11  0:41                     ` Philip Craig
  2009-08-11  0:45                       ` Philip A. Prindeville
  1 sibling, 1 reply; 22+ messages in thread
From: Philip Craig @ 2009-08-11  0:41 UTC (permalink / raw)
  To: Philip A. Prindeville
  Cc: Pavel Roskin, Luis R. Rodriguez, Jon Loeliger, wireless

Philip A. Prindeville wrote:
> * allowing a cross-compilation without contamination by the host's own state via pkg-config bleeding into it.

Setting PKG_CONFIG_LIBDIR should fix that without any makefile changes.
I haven't tried with this package, but it works for every other
cross compilation I've done.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] CRDA and cross-compilation
  2009-08-11  0:25                         ` Pavel Roskin
@ 2009-08-11  0:41                           ` Philip A. Prindeville
  2009-08-11  5:52                           ` Philip A. Prindeville
  1 sibling, 0 replies; 22+ messages in thread
From: Philip A. Prindeville @ 2009-08-11  0:41 UTC (permalink / raw)
  To: Pavel Roskin; +Cc: Luis R. Rodriguez, Jon Loeliger, wireless

[-- Attachment #1: Type: text/plain, Size: 2911 bytes --]

Pavel Roskin wrote:
> On Mon, 2009-08-10 at 16:55 -0700, Philip A. Prindeville wrote:
> 
>> You're right: that comment was much more helpful...  does it apply to the first file or the second or both?
>>
>> And what in particular is a mess?
> 
> Cross compilation is not easy.  That's why there are such
> "metadistros" (for the lack of a better word) as buildroot and
> openembedded.  They have special entries for every package that specify
> how to cross-compile it.  There are patches for many sources, although
> it's better to have such files applied to the upstream sources.  But
> it's inevitable that the build is influenced in some way to
> cross-compile, often by specifying variables on the make command line.

Yes, agreed.  We are a downstream user of buildroot.  Unfortunately, not everything we use finds its way upstream to the buildroot repo... so we make certain changes ourselves.

And it's exactly because getting the fixes upstream *is* useful (why fix it in multiple places when you can fix it once???) that I'm being persistent.

I have no problem using variables to make to influence cross-compilation.  Indeed, my patch uses "make ... CROSS_COMPILE=$(TARGET_CROSS)" to work.


> I believe the developers of buildroot and openembedded would be able to
> deal with CRDA as is.  If they find something that could be improved,
> they can send a patch, but I don't think they will bother to change so
> many things as your patch does.
> 
> Besides, it's one thing to follow sane rules that simplify
> cross-compilation, such as providing the fourth argument to
> AC_RUN_IFELSE in configure.ac or not using uname to determine the target
> architecture.  It's another thing to support cross-compilation in a way
> unique to the package.  The gain is miniscule, and the potential for
> breaking is substantial.

There are environments where using pkg-config is every bit as evil using uname.  You just haven't had the unfortunate experience of encountering any yet.

If you're volunteering to add autoconf support to crda, then I accept.  :-)

> Most importantly, you are wasting time of people who could be doing
> something they are better at, such as development of wireless drivers.

By getting wireless drivers to run in yet another environment, I'm augmenting the base of people who will test the code you write.  What I'm doing here isn't without value as well, and some collaboration might be justified.

> There is no point in pushing the same patch over and over again, just
> because you wrote it.  Please try to accept the fact that it's not
> useful for others.  Maybe it was useful for you as an exercise.  But now
> you are not helping.  Please move on and do something else.

You're contradicting yourself.  Above you agree that "specifying variables on the make command line" is a common and acceptable way to indicate cross-compilation.

That's exactly what I'm adding here.



[-- Attachment #2: crda-cross-compile.patch --]
[-- Type: text/plain, Size: 1543 bytes --]

Changes:

1. Move invariant definitions to before any cross-compilation conditional sections for clarity (and to avoid having to duplicate them).

2. Bracket any host (native) compilation sections with conditional based on $(CROSS_COMPILE) being empty.

4. Add 'else' section for cross-compilation using openssl and libnl-1 (or libnl-2 if explicitly selected).


--- crda-1.1.0/Makefile	2009-08-10 13:37:36.000000000 -0700
+++ crda-1.1.0/Makefile.new	2009-08-10 17:29:22.000000000 -0700
@@ -22,12 +22,17 @@
 # with make PUBKEY_DIR=/usr/lib/crda/pubkeys
 PUBKEY_DIR?=pubkeys
 
+MKDIR ?= mkdir -p
+INSTALL ?= install
+
 CFLAGS += -Wall -g
 
 all: all_noverify verify
 
 all_noverify: crda intersect regdbdump
 
+ifeq ($(CROSS_COMPILE),)
+
 ifeq ($(USE_OPENSSL),1)
 CFLAGS += -DUSE_OPENSSL `pkg-config --cflags openssl`
 LDLIBS += `pkg-config --libs openssl`
@@ -41,8 +46,6 @@
 reglib.o: keys-gcrypt.c
 
 endif
-MKDIR ?= mkdir -p
-INSTALL ?= install
 
 NL1FOUND := $(shell pkg-config --atleast-version=1 libnl-1 && echo Y)
 NL2FOUND := $(shell pkg-config --atleast-version=2 libnl-2.0 && echo Y)
@@ -64,6 +67,31 @@
 NLLIBS += `pkg-config --libs $(NLLIBNAME)`
 CFLAGS += `pkg-config --cflags $(NLLIBNAME)`
 
+else
+
+ifeq ($(USE_OPENSSL),1)
+CFLAGS += -DUSE_OPENSSL
+LDLIBS += -lssl
+
+reglib.o: keys-ssl.c
+
+else
+CFLAGS += -DUSE_GCRYPT
+LDLIBS += -lgcrypt
+
+reglib.o: keys-gcrypt.c
+
+endif
+
+ifeq ($(USE_LIBNL20),1)
+CFLAGS += -DCONFIG_LIBNL20
+NLLIBS = -lnl-genl -lnl-2.0
+else
+NLLIBS = -lnl
+endif
+
+endif
+
 ifeq ($(V),1)
 Q=
 NQ=@true

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] CRDA and cross-compilation
  2009-08-11  0:41                     ` Philip Craig
@ 2009-08-11  0:45                       ` Philip A. Prindeville
  0 siblings, 0 replies; 22+ messages in thread
From: Philip A. Prindeville @ 2009-08-11  0:45 UTC (permalink / raw)
  To: Philip Craig; +Cc: Pavel Roskin, Luis R. Rodriguez, Jon Loeliger, wireless

Philip Craig wrote:
> Philip A. Prindeville wrote:
>> * allowing a cross-compilation without contamination by the host's own state via pkg-config bleeding into it.
> 
> Setting PKG_CONFIG_LIBDIR should fix that without any makefile changes.
> I haven't tried with this package, but it works for every other
> cross compilation I've done.

Indeed, and that would work until, as Pavel points out, someone adds something naive and ill-informed like a `uname -r` (or `arch`) into the Makefile.

I'm not just trying to make the current version safe for cross-compilation, but all future versions too so I don't ever have to come back and fix this issue again.

You have no idea how many packages we had to make cross-compilation safe.  Literally dozens.  And some of them continue to have periodic regressions.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] CRDA and cross-compilation
  2009-08-11  0:25                         ` Pavel Roskin
  2009-08-11  0:41                           ` Philip A. Prindeville
@ 2009-08-11  5:52                           ` Philip A. Prindeville
  1 sibling, 0 replies; 22+ messages in thread
From: Philip A. Prindeville @ 2009-08-11  5:52 UTC (permalink / raw)
  To: Pavel Roskin; +Cc: Luis R. Rodriguez, Jon Loeliger, wireless

Pavel Roskin wrote:
> On Mon, 2009-08-10 at 16:55 -0700, Philip A. Prindeville wrote:
> 
>> You're right: that comment was much more helpful...  does it apply to the first file or the second or both?
>>
>> And what in particular is a mess?
> 
> Cross compilation is not easy.  That's why there are such
> "metadistros" (for the lack of a better word) as buildroot and
> openembedded.  They have special entries for every package that specify
> how to cross-compile it.  There are patches for many sources, although
> it's better to have such files applied to the upstream sources.  But
> it's inevitable that the build is influenced in some way to
> cross-compile, often by specifying variables on the make command line.
> 
> I believe the developers of buildroot and openembedded would be able to
> deal with CRDA as is.  If they find something that could be improved,
> they can send a patch, but I don't think they will bother to change so
> many things as your patch does.
> 
> Besides, it's one thing to follow sane rules that simplify
> cross-compilation, such as providing the fourth argument to
> AC_RUN_IFELSE in configure.ac or not using uname to determine the target
> architecture.  It's another thing to support cross-compilation in a way
> unique to the package.  The gain is miniscule, and the potential for
> breaking is substantial.
> 
> Most importantly, you are wasting time of people who could be doing
> something they are better at, such as development of wireless drivers.
> 
> There is no point in pushing the same patch over and over again, just
> because you wrote it.  Please try to accept the fact that it's not
> useful for others.  Maybe it was useful for you as an exercise.  But now
> you are not helping.  Please move on and do something else.

Pavel,

Consider the code in the form of the latest submission.  The conditional-compilation path *is* necessary.

Here's why.

Consider that at some point someone decides to spruce up the functionality of CRDA, perhaps by adding internationalization/NLS (just to pick an example)... and adds code for GETTEXT or some other library.

Then they decide that it isn't optional, it's a requirement.

Currently to make things build, I'd have to call:

make -C crda USE_OPENSSL=1 NL1FOUND=Y NLLIBNAME=libnl-1 NLLIBS=-lnl-1 ...

just to get it to compile successfully.

Then someone has the brilliant idea above (of adding new functionality, and making it mandatory), and adds a corresponding bit of code like:

ifeq ($(NLLIBNAME),)
$(error Cannot find development files for any supported version of libnl)
endif

to do the equivalent functionality.  Bingo.  The cross-compilation would break, and I'd have to come back and stare at the makefile and add to an ever increasing list of variables that had to be passed in.

But that's not even the worst of it.

NL1FOUND is an internal variable!  It's used as a temporary for some transient state in the makefile... It shouldn't even be externally visible, ditto for NLLIBNAME.  Yet if I don't pass this variable in, the make dies with the above $(error ...) message.

And you're telling me that my patch is a glory mess?

Not hardly.

At least my proposed fix compartmentalizes the auto-configuration bits from the list of external state that needs to be passed in, so it's quickly apparent which is which.

-Philip


^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2009-08-11 12:03 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-06  8:08 CRDA and cross-compilation Philip A. Prindeville
2009-08-06 14:46 ` Jon Loeliger
2009-08-06 16:41   ` Pavel Roskin
2009-08-06 16:56     ` Luis R. Rodriguez
2009-08-06 17:38       ` Philip A. Prindeville
2009-08-06 17:45       ` Pavel Roskin
2009-08-06 18:30         ` Philip A. Prindeville
2009-08-06 18:41           ` Pavel Roskin
2009-08-06 18:42         ` Luis R. Rodriguez
2009-08-06 19:08           ` Pavel Roskin
2009-08-06 19:23             ` Luis R. Rodriguez
     [not found]           ` <4A7BD15E.1030604@redfish-solutions.com>
     [not found]             ` <43e72e890908070905s447a2fc0j2dc086048194db34@mail.gmail.com>
     [not found]               ` <4A7CC24D.1000104@redfish-solutions.com>
     [not found]                 ` <1249698462.25983.7.camel@mj>
2009-08-10 22:13                   ` [PATCH] " Philip A. Prindeville
2009-08-10 22:30                     ` Luis R. Rodriguez
2009-08-10 23:55                       ` Philip A. Prindeville
2009-08-11  0:25                         ` Pavel Roskin
2009-08-11  0:41                           ` Philip A. Prindeville
2009-08-11  5:52                           ` Philip A. Prindeville
2009-08-11  0:41                     ` Philip Craig
2009-08-11  0:45                       ` Philip A. Prindeville
2009-08-06 19:14         ` Philip A. Prindeville
2009-08-06 19:21           ` Jon Loeliger
2009-08-06 15:09 ` John W. Linville

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).