[ On Sunday, January 21, 2001 at 20:07:09 (+0900), itojun@itojun.org wrote: ]
> Subject: bin/12017: how to enable multibyte locale (and problem around it)
>
> 	this is partly because multibyte locale support uses dlopen() from
> 	within libc.  it is unavoidable for extensibility and smaller code
> 	footprint.
> 	(if we avoid use of dlopen(), we will have locale library that is not
> 	future-proven, and netbsd binaries will become bigger due to unused
> 	locale handling code.  in the document we don't consider it an option)

Somebody had better think of making it an option VERY soon (i.e.
avoiding the use of dlopen() in static binaries for any purpose)!!!!!

There's absolutely no way any (static) binary on any of my firewall
machines is going to be dynamically loading new code!!!!  I don't even
want that happening on any of my production machines either.

If that means losing multi-byte locale support on those machines then so
be it (fortunately it doesn't directly affect me, yet), but disks are
cheap (and memory is relatively cheap) and I don't really care how big
the binaries are just so long as they are 100% absolutely guaranteed
permanently static.

There should be some way (i.e. a linker trick) to require a separate
library be specified on the command-line if one wants multi-byte locale
support enabled in libc.  This way there could be two such libraries,
one of which could use dlopen(), and the other could be static.  That
way people wanting to build application binaries that could out-live the
lifetime of any given single OS release would have a way to make them
dynamically extensible.  Meanwhile the base OS binaries could be kept
safe and secure.

In fact I'm still planning on doing some experiments with fully static
builds of the entire system just as soon as I get my second new
development server up and running on -current.  I may even investigate
the possibility of using kernel pre-loaded libraries if there seems to
be any performance benefit....

I really should have a closer look at some of the multi-byte locale APIs
involved here.  From an overview level I cannot see any reason why any
of this stuff has to be dynamically linked in any way.  It should be
possible to make a fully ``extensible'' mutli-byte handling system that
is only data driven -- surely there's no need to add new code just to
make a new locale, since by this day and age we should very well know
exactly what it takes to support even the most bizzare set of features
required by even the most non-Western locale!

The whole idea of having to make anything in libc dynamically extensible
is EXTREMELY scary from a security point of view!

To wander slightly more off topic, I also find it very silly in this day
and age of open source, particularly within an "open source" group, to
find there's any support whatsoever for the idea of using dynamic
loading to make something extensible.  *Everyone* already has access to
the source -- if you want to make something extensible then they can
easily re-compile (provided you also make your build system as robust as
your application)!  I.e. the world no longer gets frozen in stone every
time a release is cut!  Even in NetBSD you don't need dynamic linking to
support older binaries -- that's done in the kernel for goodness sake!


[[ On the other hand I agree that if you want dynamic loading for some
purpose then there's no reason why you shouldn't allow dlopen() from an
otherwise statically linked binary. ]]

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>