Bug 203540
| Summary: | Mk/Uses/compiler.mk gets called automatically only on some platforms and not on others | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | pr |
| Component: | Ports Framework | Assignee: | Port Management Team <portmgr> |
| Status: | Closed FIXED | ||
| Severity: | Affects Many People | CC: | imp, jbeich, ports-bugs |
| Priority: | --- | ||
| Version: | Latest | ||
| Hardware: | arm | ||
| OS: | Any | ||
A commit references this bug: Author: antoine Date: Mon Oct 5 16:59:52 UTC 2015 New revision: 398656 URL: https://svnweb.freebsd.org/changeset/ports/398656 Log: Add missing USES=compiler, needed for ${COMPILER_TYPE} checks PR: 203540 Changes: head/lang/gcc/Makefile head/lang/gcc5/Makefile head/lang/gcc5-devel/Makefile head/lang/gcc6-devel/Makefile The submitter didn't mention FreeBSD version but the issue likely comes from namespace pollution caused by bsd.compiler.mk implicitly included by bsd.own.mk via bsd.port.mk. It appears to be a regression from base r264661 and base r265420 (both only in /head) which moved bsd.compiler.mk outside of _WITHOUT_SRCCONF conditional defined in bsd.port.mk. Both /usr/share/mk/bsd.compiler.mk and /usr/ports/Mk/Uses/compiler.mk define the following variables: COMPILER_TYPE COMPILER_FEATURES (underpopulated) COMPILER_VERSION (incompatible values) We now use COMPILER_TYPE extensively in the build and in the other bsd.*.mk files, so it was moved out from under the _WITHOUT_SRCCONF define. In 10.x, we mostly just used it to determine what to build. In current (and some MFC'd stuff) we use it to add compiler flags and do conditional things based on what compiler we're using. It is not a regression, but a new feature. ports could adjust by undefining things after including bsd.own.mk. It's kinda half using bsd.*.mk files and half not. src could cope by renaming things. While this was in a release, it wasn't documented in 10.x as a thing that could be used. Chances are good it's leaked into downstream builds though. It might also be possible to move where we include it, but then COMPILER_FEATURES wouldn't be defined in bsd.srcopt.mk. This might actually be the least intrusive way to fix it if I can get the depends right. A commit references this bug: Author: imp Date: Tue Oct 6 04:18:49 UTC 2015 New revision: 288911 URL: https://svnweb.freebsd.org/changeset/base/288911 Log: Previous versions of bsd.own.mk included bsd.compiler.mk only when _WITHOUT_SRCCONF wasn't defined. Restore this behavior because bsd.ports.mk depends on this in subtle ways. The compat include of bsd.compiler.mk should be removed in 12 anyway. PR: 203540 Changes: head/share/mk/bsd.own.mk Turns out that we already included bsd.compiler.mk all the places we need it and only included it in bsd.own.mk for compat. So it was easy to make things a little more compat. Close: I believe the problem is fixed |
Mk/Uses/compiler.mk is triggered automatically on some platforms, I can test i386 and amd64 and not on other, I can test arm6. me@raspberry-pi:~ % cat Makefile all: @${ECHO_CMD} ${LOCALBASE} @${ECHO_CMD} ${COMPILER_TYPE} .include <bsd.port.mk> me@raspberry-pi:~ % make /usr/local me@raspberry-pi:~ % Note how in AMD64 it works: me@amd64:~ % make /usr/local clang me@amd64:~ % As a result some ports fail to build on platforms other than i386/amd64. In particular the following are affected: devel/arm-none-eabi-gcc devel/powerpc64-xtoolchain-gcc graphics/hugin lang/gcc lang/gcc5-devel lang/gcc5 lang/gcc6-devel This is because their Makefiles relay on COMPILER_TYPE (defined by Mk/Uses/compiler.mk) but they don't explicitly ask for USES+= compiler