On Thu, Apr 26, 2012 at 05:41:40PM +0400, Ruslan Ermilov wrote: > On Thu, Apr 26, 2012 at 12:35:48PM +0300, Konstantin Belousov wrote: > > I think it is time to stop building the toolchain static. I was told that > > original reasoning for static linking was the fear of loosing the ability > > to recompile if some problem appears with rtld and any required dynamic > > library. Apparently, current dependencies are much more spread, e.g. /bin/sh > > is dynamically linked, and statically linked make does not solve anything. > > ------------------------------------------------------------------------ > r76801 | sobomax | 2001-05-18 13:05:56 +0400 (Fri, 18 May 2001) | 6 lines > > By default build make(1) as a static binary. It costs only 100k of additional > disk space, buf provides measureable speed increase for make-intensive > operations, such as pkg_version(1), `make world' and so on. > > MFC after: 1 week > > ------------------------------------------------------------------------ > > Have things changed enough that the above is not true anymore? > > > Patch below makes the dynamically linked toolchain a default, adding an > > WITHOUT_SHARED_TOOLCHAIN build-time option for real conservators. > > > > I did not looked in details why including bsd.own.mk makes NO_MAN > > non-functional. Please see the diffs for gnu/usr.bin/cc1*/Makefile. > > Because you include bsd.own.mk before NO_MAN is defined, and the way > how .if works in make(1). What is the 'right' thing to do then ? Postpone the inclusion of bsd.own.mk after NO_MAN definition ? This makes the .if $MK_SHARED_TOOLCHAIN to not work. Or, continue to do what I have done, using 'MAN=' instead ? N.B. I will commit the change, with defaults kept to build toolchain static, just to avoid bikeshed.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:26 UTC