Build them as part of the bootstrap-tools phase instead.
Details
Details
buildworld+installworld succeeds for me. Not sure what do with with mkesd_static/mkcsmapper_static references in Makefile.depend.
Diff Detail
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 36405 Build 33294: arc lint + arc unit
Event Timeline
| share/i18n/esdb/Makefile.inc | ||
|---|---|---|
| 9 | The other option would be to just assume that $PATH has the right binary first. | |
| share/i18n/csmapper/Makefile.inc | ||
|---|---|---|
| 6–9 | This breaks the dirdeps build. | |
| 7 | Please don't hardcode buildworld paths into child Makefiles. There is a SYSROOT var you can use instead but that would still be wrong for the dirdeps build which wants STAGE_HOST_OBJTOP since this is not a target binary but a host binary. | |
| usr.bin/mkcsmapper_static/Makefile | ||
| 1–17 | I wonder why someone bothered to split these tools into a dynamic and static version. I suggest we understand that before this proceeds. | |
Comment Actions
Will update to just assume the tool is in $PATH to avoid hardcoded paths.
| share/i18n/csmapper/Makefile.inc | ||
|---|---|---|
| 7 | Since it's a bootstrap-tool now instead of a build tool we could just assume that it's in $PATH. Would that work for dirdeps/meta_mode? | |
| usr.bin/mkcsmapper_static/Makefile | ||
| 1–17 | My guess would be that that was the easiest way to get things to work since the host libc didn't contain the required symbols at the time. The commit logs for R10:ad30f8e79bd1007cc2476e491bd21b4f5e389e0a don't seem to explain it. | |