Bug 158013

Summary:	devel/gmake: TARGET_ARCH variable prevents cross-compilations
Product:	Ports & Packages	Reporter:	Carl <k0802647>
Component:	Individual Port(s)	Assignee:	autotools
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	Latest
Hardware:	Any
OS:	Any

Description Carl 2011-06-19 03:00:21 UTC

Please refer to the problem reports listed below which document an issue relating to the use of gmake for building FreeBSD ports. I do not profess to fully understand what is going on, but it seems that gmake incorrectly inserts the value of a TARGET_ARCH variable in the 'cc' compile command line, thereby causing a compilation error if that variable is set (see ports/156607 for example). Although it appears that TARGET_ARCH does not serve a purpose when cross-compiling most FreeBSD ports, it is a variable that users may have set in the build environment for other reasons (eg. same environment used for cross-compiling kernel or world). The obvious workaround of ensuring that variable is unset is possible for cross-compiling most ports. However, it is completely counter-intuitive and non-obvious that a variable which is not used by a port MUST be unset in order for that port to compile. This seems a clear violation of the POLA to me. Unfortunately, not all port maintainers are 
 willing to implement a fix in their port's Makefile.

http://www.freebsd.org/cgi/query-pr.cgi?pr=147853
http://www.freebsd.org/cgi/query-pr.cgi?pr=151224
http://www.freebsd.org/cgi/query-pr.cgi?pr=156607
http://www.freebsd.org/cgi/query-pr.cgi?pr=157457
http://www.freebsd.org/cgi/query-pr.cgi?pr=157479

If the FreeBSD gmake port is referencing TARGET_ARCH in a manner that serves no useful purpose in any FreeBSD context, can that functionality be patched out of the gmake port so that users do not have to intuit the undocumented need to unset TARGET_ARCH for ports cross-built with gmake?

Carl                                                 / K0802647

How-To-Repeat: Set TARGET_ARCH in the build environment and compile the security/nmap port.

Comment 1 Edwin Groothuis freebsd_committer

2011-06-19 03:00:32 UTC

Responsible Changed
From-To: freebsd-ports-bugs->autotools

Over to maintainer (via the GNATS Auto Assign Tool)

Comment 2 Ade Lovett freebsd_committer

2012-04-30 19:17:02 UTC

State Changed
From-To: open->closed

1.  Cross-compilation of /usr/ports is not supported, subtly fails to 
work in a common case (amd64->i386), falls-down-goes-boom in all 
other cases 

2.  TARGET_ARCH is used by /usr/src for cross-compilation 
TARGET_ARCH is used by GNU make for its own purposes 
The only commonality between these two is the variable name. 
"Fixing" one or the other would be an enormous undertaking, with 
zero end-result improvements (see (1) above).

Comment 3 Carl 2012-04-30 22:47:15 UTC

Cross-compilation capability is a requirement for any OS that hopes to 
be ported to a broader selection of processor architectures. So, Ade, 
let's be completely clear what you are saying by closing without fixing 
this bug. You have decided for the FreeBSD community that the gmake port 
will knowingly and deliberately be made a stumbling block to getting 
FreeBSD onto other architectures.

Would you be so kind as to point me to an official FreeBSD decision 
statement that says cross-compilation of /usr/ports is not supported? 
Perhaps that is the case, but I find it really quite astonishing that 
the common case of cross-compiling amd64 to i386 is deemed unimportant.

How you can label a fix to this bug as achieving "zero end-result 
improvements" is beyond me. Your own inexperience with such things as 
embedded applications and small network appliances does not somehow mean 
that no one else in the community has such needs. What you see as "zero" 
is very definitely non-zero when I am having to patch individual ports 
in an effort to make FreeBSD work.

Carl                                                      / K0802647