NetBSD Problem Report #18151
Received: (qmail 29877 invoked by uid 605); 2 Sep 2002 18:52:24 -0000
Message-Id: <200209021851.g82Ipao15294@bigbox.hjalmar.to>
Date: Mon, 2 Sep 2002 20:51:36 +0200 (CEST)
From: Anders Hjalmarsson <hjalmar@hjalmar.to>
Sender: gnats-bugs-owner@netbsd.org
Reply-To: hjalmar@hjalmar.to
To: gnats-bugs@gnats.netbsd.org
Subject: Multibyte locale support for statically linked programs
X-Send-Pr-Version: 3.95
>Number: 18151
>Category: lib
>Synopsis: Multibyte locale support for statically linked programs
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: lib-bug-people
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Mon Sep 02 18:53:00 +0000 2002
>Closed-Date:
>Last-Modified: Tue Sep 03 22:49:05 +0000 2002
>Originator: Anders Hjalmarsson
>Release: NetBSD 1.6F current 20020824
>Organization:
>Environment:
System: NetBSD bigbox.hjalmar.to 1.6F NetBSD 1.6F (BIGBOX-$Revision: 1.7 $) #204: Sun Sep 1 02:14:27 CEST 2002 hjalmar@bigbox.hjalmar.to:/usr/SRC/config/i386/compile/BIGBOX i386
Architecture: i386
Machine: i386
>Description:
Multibyte locales do not work in statically linked programs.
The following patches add support for compiled-in multibyte
locale modules to the static libc, the shared libc continues
to load all modules dynamically.
The set of locale modules to compile-in is specified by the
make variable STATIC_LOCALES when builing libc, the default
(in bsd.own.mk) is none.
The size increase is about 25k (i386) for a statically linked program
if all currently supported multibyte locales are compiled-in.
Known bug: The object files for the locale modules get added
to the shared libc as well. This does not seem to cause any harm
except a slight size increase, but it is ugly.
>How-To-Repeat:
Not applicable.
>Fix:
Index: share/mk/bsd.README
===================================================================
RCS file: /cvsroot/sharesrc/share/mk/bsd.README,v
retrieving revision 1.101
diff -r1.101 bsd.README
366a367,372
> STATIC_LOCALES The list of locale modules to be compiled-in in the static
> libc.a (and libc_p.a). Currently supported locales are:
> BIG5 EUC EUCTW ISO2022 MSKanji UTF8
> Defaults to "", which means that no multibyte locales
> are supported by statically linked programs.
>
Index: share/mk/bsd.own.mk
===================================================================
RCS file: /cvsroot/sharesrc/share/mk/bsd.own.mk,v
retrieving revision 1.305
diff -r1.305 bsd.own.mk
481a482,486
> # The list of locale modules to be compiled-in in the static
> # libc.a (and libc_p.a).
> #STATIC_LOCALES?=BIG5 EUC EUCTW ISO2022 MSKanji UTF8
> STATIC_LOCALES?=
>
Index: lib/libc/Makefile
===================================================================
RCS file: /cvsroot/basesrc/lib/libc/Makefile,v
retrieving revision 1.107
diff -r1.107 Makefile
41c41
< LINTFLAGS+= -w
---
> # XXX citrus modules not clean LINTFLAGS+= -w
153,154c153,155
< # workaround for I18N stuffs: build singlebyte setlocale() for libc.a,
< # multibyte for libc.so. the quirk should be removed when we support
---
> # workaround for I18N stuffs: build singlebyte, and a compiled-in set of
> # multibyte locales for libc.a, dynamically loadable multibyte locales
> # for libc.so. the quirk should be removed when we support
Index: lib/libc/citrus/Makefile.inc
===================================================================
RCS file: /cvsroot/basesrc/lib/libc/citrus/Makefile.inc,v
retrieving revision 1.2
diff -r1.2 Makefile.inc
13a14,29
> # Add the locale modules to compile-in in the static libc.a (and libc_p.a)
> # If a new locale module is added, the includes and the table in
> # citrus_module.c must be updated.
> # A new module must have the file name citrus_xxx.c where xxx is the lower
> # case name of the module.
> # Currently the modules specified by STATIC_LOCALES are included in the
> # shared libc (but never used). This is a bug.
> .if ${STATIC_LOCALES} != ""
> .PATH: ${.CURDIR}/citrus/modules
> CPPFLAGS+=-I${.CURDIR}/citrus
> .for var in ${STATIC_LOCALES}
> SRCS+= citrus_${var:tl}.c
> CPPFLAGS+=-D_I18N_STATIC_${var}
> .endfor
> .endif # STATIC_LOCALES
>
Index: lib/libc/citrus/citrus_ctype.c
===================================================================
RCS file: /cvsroot/basesrc/lib/libc/citrus/citrus_ctype.c,v
retrieving revision 1.2
diff -r1.2 citrus_ctype.c
58,59d57
< #ifdef _I18N_DYNAMIC
<
177,200d174
<
< #else
< /* !_I18N_DYNAMIC */
<
< int
< /*ARGSUSED*/
< _citrus_ctype_open(_citrus_ctype_t *rcc,
< char const *encname, void *variable, size_t lenvar,
< size_t szpriv)
< {
< if (!strcmp(encname, _CITRUS_DEFAULT_CTYPE_NAME)) {
< *rcc = &_citrus_ctype_default;
< return (0);
< }
< return (EINVAL);
< }
<
< void
< /*ARGSUSED*/
< _citrus_ctype_close(_citrus_ctype_t cc)
< {
< }
<
< #endif
Index: lib/libc/citrus/citrus_module.c
===================================================================
RCS file: /cvsroot/basesrc/lib/libc/citrus/citrus_module.c,v
retrieving revision 1.2
diff -r1.2 citrus_module.c
350a351,395
> /*
> * Compiled-in multibyte locale support for statically linked programs.
> */
>
> #include "citrus_ctype.h"
> #include "modules/citrus_big5.h"
> #include "modules/citrus_euc.h"
> #include "modules/citrus_euctw.h"
> #include "modules/citrus_iso2022.h"
> #include "modules/citrus_mskanji.h"
> #include "modules/citrus_utf8.h"
>
> #define _CITRUS_GETOPS_FUNC(_m_, _if_) _citrus_##_m_##_##_if_##_getops
>
> #define _CITRUS_LOCALE_TABLE_ENTRY(_n_) \
> { #_n_, _CITRUS_GETOPS_FUNC(_n_, ctype) }
>
> /*
> * Table of compiled-in locales.
> */
> static const struct _citrus_locale_table_rec {
> const char *name;
> _CITRUS_CTYPE_GETOPS_FUNC_BASE((*ctype_fun));
> } _citrus_static_locale_table[] = {
> #ifdef _I18N_STATIC_BIG5
> _CITRUS_LOCALE_TABLE_ENTRY(BIG5),
> #endif
> #ifdef _I18N_STATIC_EUC
> _CITRUS_LOCALE_TABLE_ENTRY(EUC),
> #endif
> #ifdef _I18N_STATIC_EUCTW
> _CITRUS_LOCALE_TABLE_ENTRY(EUCTW),
> #endif
> #ifdef _I18N_STATIC_ISO2022
> _CITRUS_LOCALE_TABLE_ENTRY(ISO2022),
> #endif
> #ifdef _I18N_STATIC_MSKanji
> _CITRUS_LOCALE_TABLE_ENTRY(MSKanji),
> #endif
> #ifdef _I18N_STATIC_UTF8
> _CITRUS_LOCALE_TABLE_ENTRY(UTF8),
> #endif
> { 0, 0 }
> };
>
352d396
< /*ARGSUSED*/
356c400,417
< return (NULL);
---
> const struct _citrus_locale_table_rec *p;
>
> _DIAGASSERT(handle != NULL);
> _DIAGASSERT(modname != NULL);
> _DIAGASSERT(ifname != NULL);
>
> /* LINTED handle is always from _citrus_load_module */
> p = (const struct _citrus_locale_table_rec *)handle;
>
> /* Sanity check, should perhaps be a _DIAGASSERT */
> if (strcmp(p->name, modname))
> return (0);
>
> /* Currently only ctype is implemented. */
> if (!strcmp(ifname, "ctype"))
> return (void *)p->ctype_fun;
> else
> return (0);
360,361c421
< /*ARGSUSED*/
< _citrus_load_module(_citrus_module_t *rhandle, char const *modname)
---
> _citrus_load_module(_citrus_module_t *rhandle, char const *encname)
362a423,435
> const struct _citrus_locale_table_rec *p;
>
> _DIAGASSERT(rhandle != NULL);
>
> for (p = _citrus_static_locale_table; p->name; p++) {
> if (!strcmp(p->name, encname)) {
> /* LINTED will be used only by _citrus_find_getops */
> *rhandle = (_citrus_module_t)p;
> return (0);
> }
> }
>
> /* Not found */
>Release-Note:
>Audit-Trail:
From: itojun@iijlab.net
To: hjalmar@hjalmar.to
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: lib/18151: Multibyte locale support for statically linked programs
Date: Tue, 03 Sep 2002 06:52:28 +0900
>>Synopsis: Multibyte locale support for statically linked programs
it has been disabled in the interest of / partition size.
itojun
From: Anders Hjalmarsson <hjalmar@hjalmar.to>
To: itojun@iijlab.net
Cc: gnats-bugs@gnats.netbsd.org, tech-userlevel@netbsd.org
Subject: Re: lib/18151: Multibyte locale support for statically linked programs
Date: Tue, 03 Sep 2002 00:22:22 +0200
> >>Synopsis: Multibyte locale support for statically linked programs
>
> it has been disabled in the interest of / partition size.
>
> itojun
While keeping stuff in the root partition small is important, if no
locale modules are compiled in (the default in my patches) the growth
would be minimal, certainly less than 1k per program. This patch brings
additional flexibility to those of us who prefer static linking for most
programs.
-hjalmar
From: itojun@iijlab.net
To: Anders Hjalmarsson <hjalmar@hjalmar.to>
Cc: gnats-bugs@gnats.netbsd.org, tech-userlevel@netbsd.org
Subject: Re: lib/18151: Multibyte locale support for statically linked programs
Date: Tue, 03 Sep 2002 07:28:23 +0900
>> >>Synopsis: Multibyte locale support for statically linked programs
>> it has been disabled in the interest of / partition size.
>While keeping stuff in the root partition small is important, if no
>locale modules are compiled in (the default in my patches) the growth
>would be minimal, certainly less than 1k per program. This patch brings
>additional flexibility to those of us who prefer static linking for most
>programs.
without locale modules compiled in there's no use in having
locale-related logic.
itojun
From: Anders Hjalmarsson <hjalmar@hjalmar.to>
To: itojun@iijlab.net
Cc: gnats-bugs@gnats.netbsd.org, tech-userlevel@netbsd.org
Subject: Re: lib/18151: Multibyte locale support for statically linked programs
Date: Tue, 03 Sep 2002 00:36:10 +0200
> >> >>Synopsis: Multibyte locale support for statically linked programs
> >> it has been disabled in the interest of / partition size.
> >While keeping stuff in the root partition small is important, if no
> >locale modules are compiled in (the default in my patches) the growth
> >would be minimal, certainly less than 1k per program. This patch brings
> >additional flexibility to those of us who prefer static linking for most
> >programs.
>
> without locale modules compiled in there's no use in having
> locale-related logic.
>
> itojun
I am sorry, I was unclear. My point was that if the default was no
multibyte locales, the extra space would be trivial, while at the same time
those who want multibyte locales in static programs can rebuild their
system with the locales of their choice by simply setting a make variable
without needing extra patches.
-hjalmar
From: woods@weird.com (Greg A. Woods)
To: hjalmar@hjalmar.to
Cc: gnats-bugs@gnats.netbsd.org (NetBSD GNATS submissions and followups),
netbsd-bugs@NetBSD.ORG (NetBSD Bugs and PR posting List)
Subject: Re: lib/18151: Multibyte locale support for statically linked programs
Date: Tue, 3 Sep 2002 12:05:45 -0400 (EDT)
[ On Monday, September 2, 2002 at 20:51:36 (+0200), Anders Hjalmarsson wrote: ]
> Subject: lib/18151: Multibyte locale support for statically linked programs
>
>
> Multibyte locales do not work in statically linked programs.
> The following patches add support for compiled-in multibyte
> locale modules to the static libc, the shared libc continues
> to load all modules dynamically.
> The set of locale modules to compile-in is specified by the
> make variable STATIC_LOCALES when builing libc, the default
> (in bsd.own.mk) is none.
> The size increase is about 25k (i386) for a statically linked program
> if all currently supported multibyte locales are compiled-in.
Very nice! Thank you!
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>
From: woods@weird.com (Greg A. Woods)
To: Anders Hjalmarsson <hjalmar@hjalmar.to>
Cc: itojun@iijlab.net, gnats-bugs@gnats.netbsd.org, tech-userlevel@netbsd.org
Subject: Re: lib/18151: Multibyte locale support for statically linked programs
Date: Tue, 3 Sep 2002 12:19:21 -0400 (EDT)
[ On Tuesday, September 3, 2002 at 00:22:22 (+0200), Anders Hjalmarsson wrote: ]
> Subject: Re: lib/18151: Multibyte locale support for statically linked programs
>
>
> > >>Synopsis: Multibyte locale support for statically linked programs
> >
> > it has been disabled in the interest of / partition size.
> >
> > itojun
>
> While keeping stuff in the root partition small is important,
Keeping the root partition small is only important for a very small
number of people and only on a very specific class of platforms (and
that number would be an even smaller number if the default install were
to recommend a reasonable-sized combined root+/usr partition and with
separate /var /tmp and /home partitions).
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>
From: Anders Hjalmarsson <hjalmar@hjalmar.to>
To: itojun@iijlab.net
Cc: netbsd-bugs@netbsd.org, gnats-bugs@gnats.netbsd.org,
tech-userlevel@netbsd.org
Subject: Re: lib/18151: Multibyte locale support for statically linked programs
Date: Tue, 03 Sep 2002 20:52:53 +0200
>
> without locale modules compiled in there's no use in having
> locale-related logic.
>
> itojun
Here is a revised version of the patches. I hope this addresses your
concerns. If STATIC_LOCALES is empty the old stubs are used, so everything
is like before, the new code is only used if STATIC_LOCALES is non-empty.
-hjalmar
Index: share/mk/bsd.README
===================================================================
RCS file: /cvsroot/sharesrc/share/mk/bsd.README,v
retrieving revision 1.101
diff -u -r1.101 bsd.README
--- bsd.README 2002/08/19 14:51:58 1.101
+++ bsd.README 2002/09/03 18:45:36
@@ -364,6 +364,12 @@
point and possibly soft-float library support. Defaults
to "no".
+STATIC_LOCALES The list of locale modules to be compiled-in in the static
+ libc.a (and libc_p.a). Currently supported locales are:
+ BIG5 EUC EUCTW ISO2022 MSKanji UTF8
+ Defaults to "", which means that no multibyte locales
+ are supported by statically linked programs.
+
bsd.own.mk is generally useful when building your own Makefiles so that
they use the same default owners etc. as the rest of the tree.
Index: share/mk/bsd.own.mk
===================================================================
RCS file: /cvsroot/sharesrc/share/mk/bsd.own.mk,v
retrieving revision 1.305
diff -u -r1.305 bsd.own.mk
--- bsd.own.mk 2002/08/03 22:10:07 1.305
+++ bsd.own.mk 2002/09/03 18:45:37
@@ -479,4 +479,9 @@
USE_XF86_4?= yes
.endif
+# The list of locale modules to be compiled-in in the static
+# libc.a (and libc_p.a).
+#STATIC_LOCALES?=BIG5 EUC EUCTW ISO2022 MSKanji UTF8
+STATIC_LOCALES?=
+
.endif # _BSD_OWN_MK_
Index: lib/libc/Makefile
===================================================================
RCS file: /cvsroot/basesrc/lib/libc/Makefile,v
retrieving revision 1.107
diff -u -r1.107 Makefile
--- Makefile 2002/08/19 14:55:14 1.107
+++ Makefile 2002/09/03 18:45:50
@@ -38,7 +38,7 @@
.if ${MACHINE_ARCH} == "i386"
# Set lint to exit on warnings
-LINTFLAGS+= -w
+# XXX citrus modules not clean LINTFLAGS+= -w
.endif
# ignore 'empty translation unit' warnings.
LINTFLAGS+= -X 272
@@ -150,8 +150,9 @@
FILESDIR= /var/db
-# workaround for I18N stuffs: build singlebyte setlocale() for libc.a,
-# multibyte for libc.so. the quirk should be removed when we support
+# workaround for I18N stuffs: build singlebyte, and a compiled-in set of
+# multibyte locales for libc.a, dynamically loadable multibyte locales
+# for libc.so. the quirk should be removed when we support
# dlopen() from within statically linked binaries.
CSHLIBFLAGS+= -D_I18N_DYNAMIC
Index: lib/libc/citrus/Makefile.inc
===================================================================
RCS file: /cvsroot/basesrc/lib/libc/citrus/Makefile.inc,v
retrieving revision 1.2
diff -u -r1.2 Makefile.inc
--- Makefile.inc 2002/08/19 13:35:06 1.2
+++ Makefile.inc 2002/09/03 18:45:53
@@ -11,6 +11,23 @@
SRCS+= citrus_ctype.c citrus_module.c citrus_none.c
+# Add the locale modules to compile-in in the static libc.a (and libc_p.a)
+# If a new locale module is added, the includes and the table in
+# citrus_module.c must be updated.
+# A new module must have the file name citrus_xxx.c where xxx is the lower
+# case name of the module.
+# Currently the modules specified by STATIC_LOCALES are included in the
+# shared libc (but never used). This is a bug.
+.if ${STATIC_LOCALES} != ""
+.PATH: ${.CURDIR}/citrus/modules
+CPPFLAGS+=-I${.CURDIR}/citrus
+CPPFLAGS+=-D_I18N_STATIC
+.for var in ${STATIC_LOCALES}
+SRCS+= citrus_${var:tl}.c
+CPPFLAGS+=-D_I18N_STATIC_${var}
+.endfor
+.endif # STATIC_LOCALES
+
# to be dynamically loaded - see lib/i18n_module
#SRCS+= citrus_big5.c citrus_euc.c citrus_euctw.c citrus_iso2022.c \
# citrus_mskanji.c citrus_utf8.c
Index: lib/libc/citrus/citrus_ctype.c
===================================================================
RCS file: /cvsroot/basesrc/lib/libc/citrus/citrus_ctype.c,v
retrieving revision 1.2
diff -u -r1.2 citrus_ctype.c
--- citrus_ctype.c 2002/03/18 09:02:50 1.2
+++ citrus_ctype.c 2002/09/03 18:45:53
@@ -55,7 +55,7 @@
NULL /* ce_module */
};
-#ifdef _I18N_DYNAMIC
+#if defined(_I18N_DYNAMIC) || defined(_I18N_STATIC)
static int _initctypemodule(_citrus_ctype_t, char const *, _citrus_module_t,
void *, size_t, size_t);
@@ -176,7 +176,7 @@
}
#else
-/* !_I18N_DYNAMIC */
+/* !(_I18N_DYNAMIC || _I18N_STATIC) */
int
/*ARGSUSED*/
Index: lib/libc/citrus/citrus_module.c
===================================================================
RCS file: /cvsroot/basesrc/lib/libc/citrus/citrus_module.c,v
retrieving revision 1.2
diff -u -r1.2 citrus_module.c
--- citrus_module.c 2002/04/20 05:55:47 1.2
+++ citrus_module.c 2002/09/03 18:45:53
@@ -345,22 +345,118 @@
if (handle)
dlclose((void *)handle);
}
-#else
-/* !_I18N_DYNAMIC */
+#elif defined(_I18N_STATIC)
+
+/*
+ * Compiled-in multibyte locale support for statically linked programs.
+ */
+
+#include "citrus_ctype.h"
+#include "modules/citrus_big5.h"
+#include "modules/citrus_euc.h"
+#include "modules/citrus_euctw.h"
+#include "modules/citrus_iso2022.h"
+#include "modules/citrus_mskanji.h"
+#include "modules/citrus_utf8.h"
+
+#define _CITRUS_GETOPS_FUNC(_m_, _if_) _citrus_##_m_##_##_if_##_getops
+
+#define _CITRUS_LOCALE_TABLE_ENTRY(_n_) \
+{ #_n_, _CITRUS_GETOPS_FUNC(_n_, ctype) }
+/*
+ * Table of compiled-in locales.
+ */
+static const struct _citrus_locale_table_rec {
+ const char *name;
+ _CITRUS_CTYPE_GETOPS_FUNC_BASE((*ctype_fun));
+} _citrus_static_locale_table[] = {
+#ifdef _I18N_STATIC_BIG5
+ _CITRUS_LOCALE_TABLE_ENTRY(BIG5),
+#endif
+#ifdef _I18N_STATIC_EUC
+ _CITRUS_LOCALE_TABLE_ENTRY(EUC),
+#endif
+#ifdef _I18N_STATIC_EUCTW
+ _CITRUS_LOCALE_TABLE_ENTRY(EUCTW),
+#endif
+#ifdef _I18N_STATIC_ISO2022
+ _CITRUS_LOCALE_TABLE_ENTRY(ISO2022),
+#endif
+#ifdef _I18N_STATIC_MSKanji
+ _CITRUS_LOCALE_TABLE_ENTRY(MSKanji),
+#endif
+#ifdef _I18N_STATIC_UTF8
+ _CITRUS_LOCALE_TABLE_ENTRY(UTF8),
+#endif
+ { 0, 0 }
+};
+
void *
-/*ARGSUSED*/
_citrus_find_getops(_citrus_module_t handle, const char *modname,
const char *ifname)
{
- return (NULL);
+ const struct _citrus_locale_table_rec *p;
+
+ _DIAGASSERT(handle != NULL);
+ _DIAGASSERT(modname != NULL);
+ _DIAGASSERT(ifname != NULL);
+
+ /* LINTED handle is always from _citrus_load_module */
+ p = (const struct _citrus_locale_table_rec *)handle;
+
+ /* Sanity check, should perhaps be a _DIAGASSERT */
+ if (strcmp(p->name, modname))
+ return (NULL);
+
+ /* Currently only ctype is implemented. */
+ if (!strcmp(ifname, "ctype"))
+ return (void *)p->ctype_fun;
+ else
+ return (NULL);
+}
+
+int
+_citrus_load_module(_citrus_module_t *rhandle, char const *encname)
+{
+ const struct _citrus_locale_table_rec *p;
+
+ _DIAGASSERT(rhandle != NULL);
+
+ for (p = _citrus_static_locale_table; p->name; p++) {
+ if (!strcmp(p->name, encname)) {
+ /* LINTED will be used only by _citrus_find_getops */
+ *rhandle = (_citrus_module_t)p;
+ return (0);
+ }
+ }
+
+ /* Not found */
+ return (EINVAL);
}
+void
+/*ARGSUSED*/
+_citrus_unload_module(_citrus_module_t handle)
+{
+}
+
+#else
+/* No static multibyte locales */
+
int
/*ARGSUSED*/
-_citrus_load_module(_citrus_module_t *rhandle, char const *modname)
+_citrus_load_module(_citrus_module_t *rhandle, char const *encname)
{
return (EINVAL);
+}
+
+void *
+/*ARGSUSED*/
+_citrus_find_getops(_citrus_module_t handle, const char *modname,
+ const char *ifname)
+{
+ return (NULL);
}
void
From: Anders Hjalmarsson <hjalmar@hjalmar.to>
To: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Cc: gnats-bugs@gnats.netbsd.org, netbsd-bugs@NetBSD.ORG,
tech-userlevel@NetBSD.ORG
Subject: Re: lib/18151: Multibyte locale support for statically linked programs
Date: Wed, 04 Sep 2002 00:47:39 +0200
> >Here is a revised version of the patches. I hope this addresses your
> >concerns. If STATIC_LOCALES is empty the old stubs are used, so everything
> >is like before, the new code is only used if STATIC_LOCALES is non-empty.
>
> actually, all binaries will become dynamically-linked (saw message
> on current-users?) so not sure if this patch is needed any longer.
>
> itojun
Actually there was a vocal minority which wanted to be able to static link
at least /bin and /sbin, so even if the default changes to dynamic linking
of everything, many will still continue to link at least some programs
statically.
-hjalmar
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home