[RFC] Un-staticise the toolchain

Konstantin Belousov kostikbel at gmail.com
Fri Apr 27 08:59:16 UTC 2012

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20120427/e5b9bdb1/attachment.pgp

More information about the freebsd-current mailing list