Skip to contentSkip to conversation

CRDA and cross-compilation

PATCH In review Philip A. Prindeville 6 participants 22 messages Aug 6, 2009 – Aug 11, 2009 4 messages not in the archive Kbuild

lore
Share & tools
lore

Philip A. Prindeville

author
#0 lore raw

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.

Makefile renamed from Makefile.orig +44 -12
@@ -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)
#1 lore raw
Quoted 9 lines · Philip A. Prindeville

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

#2 lore raw
Quoted 9 lines · Jon Loeliger
Quoted 8 lines · Philip A. Prindeville

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

Quoted 8 lines
Quoted 1 line

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.

Signature · 2 lines
Regards,
Pavel Roskin
#3 lore raw
Quoted 15 lines · Pavel Roskin
Quoted 14 lines · Jon Loeliger
Quoted 9 lines · Philip A. Prindeville

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.

Quoted 7 lines
Quoted 3 lines

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.

Quoted 1 line

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

Agreed.

Quoted 3 lines

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.

Quoted 6 lines

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

author
#4 lore raw
Quoted 36 lines · Luis R. Rodriguez
Quoted 14 lines · Pavel Roskin
Quoted 13 lines · Jon Loeliger
Quoted 9 lines · Philip A. Prindeville

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.

Quoted 6 lines
Quoted 3 lines

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.

Quoted 1 line

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

Agreed.

Quoted 3 lines

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.

Quoted 2 lines

For instance, you can have this in Makefile:

Quoted 8 lines
Quoted 4 lines

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

#5 lore raw
In reply to Luis R. Rodriguez
Quoted 1 line · Luis R. Rodriguez

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 <[email protected]>
---
 Makefile |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)
Makefile +5 -2
index b93b735..3cc61c2 100644
@@ -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
Signature · 2 lines
Regards,
Pavel Roskin
author
#6 lore raw
Quoted 9 lines · Pavel Roskin
Quoted 1 line · Luis R. Rodriguez

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.

Quoted 9 lines

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

#7 lore raw
Quoted 1 line · Philip A. Prindeville

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

Signature · 2 lines
Regards,
Pavel Roskin
#8 lore raw
In reply to Pavel Roskin
Quoted 34 lines · Pavel Roskin
Quoted 1 line · Luis R. Rodriguez

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 <[email protected]>

---
 Makefile |    7 +++++--

 1 files changed, 5 insertions(+), 2 deletions(-)
Makefile +0 -0
index b93b735..3cc61c2 100644
@@ -24,7 +24,9 @@ PUBKEY_DIR?=pubkeys

 CFLAGS += -Wall -g

Makefile PUBKEY_DIR?=pubkeys · line 29

Quoted 4 lines
Makefile +3 -1
-all: $(REG_BIN) crda intersect verify
+all: all_noverify verify
+
+all_noverify: crda intersect regdbdump

You removed REG_BIN from here, was that intentional?

Quoted 21 lines

 ifeq ($(USE_OPENSSL),1)
 CFLAGS += -DUSE_OPENSSL pkg-config --cflags openssl

Makefile +0 -0
@@ -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

#9 lore raw
Quoted 6 lines · Luis R. Rodriguez

Makefile PUBKEY_DIR?=pubkeys · line 29

Quoted 4 lines
Makefile +3 -1
-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)

Signature · 2 lines
Regards,
Pavel Roskin
#10 lore raw
Quoted 11 lines · Pavel Roskin
Quoted 6 lines · Luis R. Rodriguez

Makefile PUBKEY_DIR?=pubkeys · line 29

Quoted 4 lines
Makefile +3 -1
-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

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 1249698462.25983.7.camel@mj

author
#15 lore raw

PATCH 1/1 CRDA and cross-compilation

Quoted 13 lines · Pavel Roskin
Quoted 6 lines · Philip A. Prindeville
Quoted 4 lines · Luis R. Rodriguez

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.

...

Quoted 2 lines

-else
+ else

...

Quoted 1 line

+install-rb: wireless-regdb/regulatory.bin

Quoted 8 lines

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

Makefile.new renamed from Makefile +43 -15
@@ -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.

Makefile.new renamed from Makefile +8 -0
@@ -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
#16 lore raw
Quoted 181 lines · Philip A. Prindeville
Quoted 13 lines · Pavel Roskin
Quoted 6 lines · Philip A. Prindeville
Quoted 4 lines · Luis R. Rodriguez

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.

...

Quoted 2 lines

-else
+ else

...

Quoted 1 line

+install-rb: wireless-regdb/regulatory.bin

Quoted 8 lines

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

Makefile.new     2009-08-10 13:37:11.000000000 -0700 renamed from Makefile 2009-08-10 13:37:36.000000000 -0700 +0 -0
@@ -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

Makefile.new     2009-08-10 13:37:11.000000000 -0700 renamed from Makefile 2009-08-10 13:37:36.000000000 -0700 +3 -3
-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
Makefile.new     2009-08-10 13:37:11.000000000 -0700 renamed from Makefile 2009-08-10 13:37:36.000000000 -0700 +0 -0
@@ -14,7 +14,7 @@

 UDEV_LEVEL=$(CRDA_UDEV_LEVEL)-
 # You can customize this if your distributions uses

 # a different location.
Makefile.new     2009-08-10 13:37:11.000000000 -0700 renamed from Makefile 2009-08-10 13:37:36.000000000 -0700 +1 -1
-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
Makefile.new     2009-08-10 13:37:11.000000000 -0700 renamed from Makefile 2009-08-10 13:37:36.000000000 -0700 +0 -0
@@ -22,48 +22,76 @@
  # with make PUBKEY_DIR=/usr/lib/crda/pubkeys

 PUBKEY_DIR?=pubkeys

Makefile.new     2009-08-10 13:37:11.000000000 -0700 renamed from Makefile 2009-08-10 13:37:36.000000000 -0700 +3 -0
+MKDIR ?= mkdir -p
+INSTALL ?= install
+

 CFLAGS += -Wall -g

 all: all_noverify verify

 all_noverify: crda intersect regdbdump

Makefile.new     2009-08-10 13:37:11.000000000 -0700 renamed from Makefile 2009-08-10 13:37:36.000000000 -0700 +3 -1
-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

Makefile.new     2009-08-10 13:37:11.000000000 -0700 renamed from Makefile 2009-08-10 13:37:36.000000000 -0700 +1 -3
-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

Makefile.new     2009-08-10 13:37:11.000000000 -0700 renamed from Makefile 2009-08-10 13:37:36.000000000 -0700 +2 -2
-endif
+ endif
 
-ifeq ($(NL2FOUND),Y)
+ ifeq ($(NL2FOUND),Y)

 CFLAGS += -DCONFIG_LIBNL20
 NLLIBS += -lnl-genl
 NLLIBNAME = libnl-2.0

Makefile.new     2009-08-10 13:37:11.000000000 -0700 renamed from Makefile 2009-08-10 13:37:36.000000000 -0700 +2 -2
-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)

Makefile.new     2009-08-10 13:37:11.000000000 -0700 renamed from Makefile 2009-08-10 13:37:36.000000000 -0700 +25 -0
+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.

Makefile.new     2009-08-10 13:37:11.000000000 -0700 renamed from Makefile 2009-08-10 13:37:36.000000000 -0700 +0 -0
@@ -136,6 +164,14 @@

       $(NQ) '  INSTALL  regdbdump.8.gz'
       $(Q)$(INSTALL) -m 644 -t $(DESTDIR)/$(MANDIR)/man8/ regdbdump.8.gz

Makefile.new     2009-08-10 13:37:11.000000000 -0700 renamed from Makefile 2009-08-10 13:37:36.000000000 -0700 +8 -0
+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
+
Quoted 3 lines

 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

author
#17 lore raw
Quoted 187 lines · Luis R. Rodriguez
Quoted 172 lines · Philip A. Prindeville
Quoted 12 lines · Pavel Roskin
Quoted 6 lines · Philip A. Prindeville
Quoted 4 lines · Luis R. Rodriguez

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.

...

Quoted 2 lines

-else
+ else

...

Quoted 1 line

+install-rb: wireless-regdb/regulatory.bin

Quoted 8 lines

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

Makefile.new 2009-08-10 13:37:11.000000000 -0700 renamed from Makefile 2009-08-10 13:37:36.000000000 -0700 +43 -15
@@ -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.

Makefile.new 2009-08-10 13:37:11.000000000 -0700 renamed from Makefile 2009-08-10 13:37:36.000000000 -0700 +1 -0
@@ -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

Makefile.new 2009-08-10 13:37:11.000000000 -0700 line 177

Quoted 10 lines
Makefile.new 2009-08-10 13:37:11.000000000 -0700 renamed from Makefile 2009-08-10 13:37:36.000000000 -0700 +7 -0
+       $(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.

Quoted 1 line

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

#18 lore raw
Quoted 3 lines · Philip A. Prindeville

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.

Signature · 2 lines
Regards,
Pavel Roskin
author
#19 lore raw
Quoted 6 lines · Pavel Roskin
Quoted 3 lines · Philip A. Prindeville

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?

Quoted 7 lines

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.

Quoted 11 lines

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

Quoted 2 lines

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.

Quoted 4 lines

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.

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

Makefile.new renamed from Makefile +30 -2
@@ -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
author
#20 lore raw
In reply to Pavel Roskin
Quoted 26 lines · Pavel Roskin
Quoted 3 lines · Philip A. Prindeville

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.

Quoted 7 lines

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

#21 lore raw
In reply to Philip A. Prindeville
Quoted 1 line · Philip A. Prindeville

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

author
#22 lore raw
Quoted 6 lines · Philip Craig
Quoted 1 line · Philip A. Prindeville

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

author
#23 lore raw
In reply to Pavel Roskin
Quoted 46 lines · Pavel Roskin
Quoted 1 line · Luis R. Rodriguez

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 <[email protected]>
---
 Makefile |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)
Makefile +3 -1
index b93b735..3cc61c2 100644
@@ -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

Makefile $(REG_BIN): · line 87

Quoted 10 lines
Makefile +2 -1
-	$(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

#24 lore raw
Quoted 4 lines · Philip A. Prindeville

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