Trying to cross-build /usr/ports/security/nmap with the following command results in a compilation failure: env TARGET_ARCH=i386 make The error message is: cc: i386: No such file or directory This is the identical problem documented in all of the following problem reports: 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 In addition to fixing the problem for security/nmap, please, please, please assign someone knowledgeable about this problem to the task of searching the entire ports collection for all instances of this same bug, rather than hoping random end users will eventually discover and report them all one at a time. It is simply wrong to waste end user time that way! Carl / K0802647 Fix: The attached patch applied to /usr/ports/security/nmap/Makefile fixed the problem for me, just as similar patches worked for problem reports ports/147853, ports/151224, ports/156607, and ports/157457. Note that the eventually committed fix for ports/156607 is implemented differently. Since I do not really understand the problem, my patch is not intended to imply an optimal solution. Patch attached with submission follows: How-To-Repeat: env TARGET_ARCH=i386 make
Responsible Changed From-To: freebsd-ports-bugs->ohauer Over to maintainer (via the GNATS Auto Assign Tool)
State Changed From-To: open->analyzed will look into this
TARGET_ARCH is valid for "/usr/src" but useless for ports so I don't want to add your fix. In case you have TARGET_ARCH specified in some automated build scripts I suggest the following entry or fixing those scripts. file /etc/make.conf =================== .if ${.CURDIR:M/usr/ports/*} .if defined(TARGET_ARCH) && !empty(TARGET_ARCH) MAKE_ENV+= TARGET_ARCH= .endif .endif With a quick search I can only find two ports which maybe use TARGET_ARCH in the way you try to build your ports (not tested). - lang/mlton - java/openjdk7 For the following ports TARGET_ARCH is valid and used to decide the build_rules used by (cd /usr/src/release ; make release) - sysutils/cdrtools - sysutils/cdrtools-devel For the port "sysutils/etcupdate" TARGET_ARCH is valid to decide which /usr/src/etc.xxx is used. // olli
State Changed From-To: analyzed->closed - wontfix TARGET_ARCH should be used only in /usr/src by users
On 2011-06-03 1:26 PM, Olli Hauer wrote: > TARGET_ARCH is valid for "/usr/src" but useless for ports so I don't > want to add your fix. I must say that I am quite taken aback at that response. Simply put, your port fails to cross-build when a variable is present in the environment that your port does not require. In fact, your port has a requirement that a variable it does not need must NOT be present in the environment. IMHO, that is both bizarre and a violation of the POLA. Are there any other variables that end users should be aware of that security/nmap doesn't use that need to be explicitly removed from the build environment in case they appear? The fix is simple. Please reconsider. Carl