Date: Sat, 23 Apr 2005 02:20:23 GMT From: Giorgos Keramidas <keramida@freebsd.org> To: freebsd-bugs@FreeBSD.org Subject: Re: docs/80258: [PATCH] Comment why some Binaries are statically linked Message-ID: <200504230220.j3N2KNAY019568@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/80258; it has been noted by GNATS.
From: Giorgos Keramidas <keramida@freebsd.org>
To: Marius Nuennerich <marius.nuennerich@gmx.net>
Cc: bug-followup@freebsd.org
Subject: Re: docs/80258: [PATCH] Comment why some Binaries are statically linked
Date: Sat, 23 Apr 2005 05:16:53 +0300
On 2005-04-22 19:56, Marius Nuennerich <marius.nuennerich@gmx.net> wrote:
> Some Binaries are statically linked, add comments to the Makefile why this is so.
> diff -ru src/gnu/usr.bin/binutils/ar/Makefile head/gnu/usr.bin/binutils/ar/Makefile
> --- src/gnu/usr.bin/binutils/ar/Makefile Thu Apr 21 16:29:47 2005
> +++ head/gnu/usr.bin/binutils/ar/Makefile Fri Apr 22 18:24:20 2005
> @@ -10,7 +10,10 @@
> CFLAGS+= -I${.CURDIR}/${RELTOP}/libbinutils
> CFLAGS+= -I${SRCDIR}/binutils
> CFLAGS+= -I${SRCDIR}/bfd
> +
> +# Critical toolchain binaries are staticly linked
> NO_SHARED?= yes
Sorry, but this is no explanation of "why". It's merely a redundant
comment that states the obvious. A _REAL_ explanation would be
something like (entirely fictitious text, used as example only):
# The dynamic linker may have to call ar(1), so it must be
# statically linked to avoid creating a circular dependency of
# ld-elf.so -> ar -> lf-elf.so
NO_SHARED?= yes
The same is true for all the "Critical toolchain binaries" comments.
> --- src/gnu/usr.bin/cc/cc1/Makefile Thu Apr 21 16:29:55 2005
> +++ head/gnu/usr.bin/cc/cc1/Makefile Fri Apr 22 19:24:54 2005
> @@ -8,6 +8,9 @@
> SRCS= main.c c-parse+%DIKED.c c-lang.c stub-objc.c
> BINDIR= /usr/libexec
> NO_MAN=
> +
> +# Build cc1 nonshared. This actually results in it consuming 40K *less* disk
> +# space and improves compile times by a few percent.
> NO_SHARED?=yes
If this comment is true, then it looks like a good thing to have :-)
> diff -ru src/gnu/usr.bin/cc/cc1plus/Makefile head/gnu/usr.bin/cc/cc1plus/Makefile
> --- src/gnu/usr.bin/cc/cc1plus/Makefile Thu Apr 21 16:29:55 2005
> +++ head/gnu/usr.bin/cc/cc1plus/Makefile Fri Apr 22 19:31:54 2005
> @@ -13,6 +13,8 @@
>
> BINDIR= /usr/libexec
> NO_MAN=
> +
> +# Makes it smaller and faster
> NO_SHARED?=yes
s/it/cc1plus/ and this looks fine too :-)
> diff -ru src/sbin/devd/Makefile head/sbin/devd/Makefile
> --- src/sbin/devd/Makefile Thu Apr 21 16:35:48 2005
> +++ head/sbin/devd/Makefile Fri Apr 22 18:22:22 2005
> @@ -5,6 +5,11 @@
> MAN= devd.8 devd.conf.5
> WARNS?= 1
>
> +# Force devd to be statically compiled. This avoids the
> +# need for libstdc++ in /lib, and the generated binary is actually smaller
> +# statically linked than dynamically + sizeof(libstdc++). Additionally,
> +# devd doesn't use get*by*() which is one of the main motivations for
> +# dynamically linking the root partition anyway.
> NO_SHARED?=YES
The wrapping of text in this comment looks like it has been randomly
chosen and there are a few glaring syntax errors.
> diff -ru src/usr.sbin/pccard/Makefile.inc head/usr.sbin/pccard/Makefile.inc
> --- src/usr.sbin/pccard/Makefile.inc Thu Apr 21 16:42:21 2005
> +++ head/usr.sbin/pccard/Makefile.inc Fri Apr 22 18:31:57 2005
> @@ -1,5 +1,7 @@
> # $FreeBSD: src/usr.sbin/pccard/Makefile.inc,v 1.9 2004/12/21 09:59:45 ru Exp $
>
> +# Must be compiled static so that it is possible
> +# to use them early in the boot process.
> NO_SHARED?= YES
This is not a complete sentence, which is a violation of style(9).
Something like this would probably look better:
# The PC-CARD tools may need to be used very early in the boot process.
NO_SHARED?= yes
One last important comment is that all these changes, despite being in
the comments of files, are *not* documentation problems. Any changes
made to the Makefiles need to be reviewed by at least one src committer.
- Giorgos
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200504230220.j3N2KNAY019568>