Re: lib/53722: Static binaries don't support locales that are implemented using shared objects

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR lib/53722; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: christos%zoulas.com@localhost (Christos Zoulas)
Cc: Martin Husemann <martin%duskware.de@localhost>, gnats-bugs%NetBSD.org@localhost,
        lib-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost, ca6c%bitmessage.ch@localhost
Subject: Re: lib/53722: Static binaries don't support locales that are implemented using shared objects
Date: Mon, 12 Nov 2018 08:00:09 +0700

     Date:        Sun, 11 Nov 2018 18:37:00 -0500
     From:        christos%zoulas.com@localhost (Christos Zoulas)
     Message-ID:  <20181111233700.48ED117FDA1%rebar.astron.com@localhost>
 
   | I think though that the locale can be fixed the same way the pam was (by
   | loading all the known locales).
 
 Why are we using dynamic linking for locales?   Sure, that should work, but
 a local is just a bunch of data, is it not?   Wouldn't just malloc()ing a space
 to stick it, and doing a simple read() work?   Or at worst, reading a header
 to find out how many structs are needed, then malloc() and read() the rest.
 
 What does using dynamic linking really achieve (aside from that the support
 is there already, and needed for other stuff.)
 
 kre