NetBSD Problem Report #53722

From www@NetBSD.org  Sun Nov 11 08:48:37 2018
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id EBC817A16A
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 11 Nov 2018 08:48:36 +0000 (UTC)
Message-Id: <20181111084836.083337A1E3@mollari.NetBSD.org>
Date: Sun, 11 Nov 2018 08:48:36 +0000 (UTC)
From: ca6c@bitmessage.ch
Reply-To: ca6c@bitmessage.ch
To: gnats-bugs@NetBSD.org
Subject: Static binaries don't support locales that are implemented using shared objects
X-Send-Pr-Version: www-1.0

>Number:         53722
>Category:       lib
>Synopsis:       Static binaries don't support locales that are implemented using shared objects
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 11 08:50:00 +0000 2018
>Last-Modified:  Mon Nov 12 01:40:01 +0000 2018
>Originator:     Cág
>Release:        NetBSD 8.99.25
>Organization:
>Environment:
NetBSD deceasedsun 8.99.25 NetBSD 8.99.25 (CUSTOM_DECEASED_SUN) #0: Wed Oct 17 16:12:41 CDT 2018  caoc@deceasedsun:/usr/src/sys/arch/amd64/compile/CUSTOM_DECEASED_SUN amd64
>Description:
Statically linked ls(1) and getty(8) do not support UTF-8 locales, and work as if they would in a C locale, despite corresponding environment variables regarding locales being set.
>How-To-Repeat:
Link ls(1) and getty(8) statically.
>Fix:

>Audit-Trail:
From: Jason Thorpe <thorpej@me.com>
To: "gnats-bugs@netbsd.org" <gnats-bugs@NetBSD.org>
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: lib/53722: Static binaries don't support locales that are
 implemented using shared objects
Date: Sun, 11 Nov 2018 06:59:32 -0800

 > On Nov 11, 2018, at 12:50 AM, ca6c@bitmessage.ch wrote:
 >> Description:
 > Statically linked ls(1) and getty(8) do not support UTF-8 locales, and =
 work as if they would in a C locale, despite corresponding environment =
 variables regarding locales being set.

 Um, behaves correctly?

 >> How-To-Repeat:
 > Link ls(1) and getty(8) statically.
 >> Fix:
 >=20

 Why are you linking these two programs statically?

 -- thorpej

From: =?UTF-8?Q?C=C3=A1g?= <ca6c@bitmessage.ch>
To: gnats-bugs@netbsd.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org
Subject: Re: lib/53722: Static binaries don't support locales that are
 implemented using shared objects
Date: Sun, 11 Nov 2018 10:09:50 -0600

 Jason Thorpe wrote:

 >> Statically linked ls(1) and getty(8) do not support UTF-8 locales, and
 >> work as if they would in a C locale, despite corresponding environment
 >> variables regarding locales being set.
 >  Um, behaves correctly?

 Discussed here[0] and in private with Christos@, so shout out to him.

 >  Why are you linking these two programs statically?

 I am linking everything statically.

 [0]: 
 http://mail-index.netbsd.org/current-users/2018/11/05/msg034545.html

 --
 caóc

From: coypu@sdf.org
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/53722: Static binaries don't support locales that are
 implemented using shared objects
Date: Sun, 11 Nov 2018 23:08:02 +0000

 The premise is wrong though...

 fly@planets ~> cat test.c
 #include <stdio.h>
 int main() {
 	printf("Hello World!\n");
 	return 0;
 }
 fly@planets ~> cc test.c -static -o static; cc test.c -o dynamic
 fly@planets ~> ls -lh dynamic static
 -rwxr-xr-x  1 fly  users  7.8K Nov 12 01:05 dynamic
 -rwxr-xr-x  1 fly  users  180K Nov 12 01:05 static

 a static system is going to be bigger

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, ca6c@bitmessage.ch
Subject: Re: lib/53722: Static binaries don't support locales that are
 implemented using shared objects
Date: Mon, 12 Nov 2018 00:22:55 +0100

 On Sun, Nov 11, 2018 at 11:10:01PM +0000, coypu@sdf.org wrote:
 >  fly@planets ~> cc test.c -static -o static; cc test.c -o dynamic
 >  fly@planets ~> ls -lh dynamic static
 >  -rwxr-xr-x  1 fly  users  7.8K Nov 12 01:05 dynamic
 >  -rwxr-xr-x  1 fly  users  180K Nov 12 01:05 static
 >  
 >  a static system is going to be bigger

 You need to also count in size of shared libraries and you did not consider
 the "whole thing" being crunched into a single binary (crunchgen or
 busybox).

 However, shared libraries not being loadable from static binaries is
 not that unexpected - and some locales and pam being unavailable is
 a well known drawback of static linking.

 Not unsolvable (hi joerg!), but not high priority nor a real bug.

 Martin

From: christos@zoulas.com (Christos Zoulas)
To: Martin Husemann <martin@duskware.de>, gnats-bugs@NetBSD.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org, 
	netbsd-bugs@netbsd.org, ca6c@bitmessage.ch
Subject: Re: lib/53722: Static binaries don't support locales that are implemented using shared objects
Date: Sun, 11 Nov 2018 18:37:00 -0500

 On Nov 12, 12:22am, martin@duskware.de (Martin Husemann) wrote:
 -- Subject: Re: lib/53722: Static binaries don't support locales that are imp

 | You need to also count in size of shared libraries and you did not consider
 | the "whole thing" being crunched into a single binary (crunchgen or
 | busybox).
 | 
 | However, shared libraries not being loadable from static binaries is
 | not that unexpected - and some locales and pam being unavailable is
 | a well known drawback of static linking.

 pam and nsswitch are partially available (the default system ones are compiled
 in, but new ones can't be loaded).
 locale is not available (only the c locale is available, and new ones can't
 be loaded)

 | Not unsolvable (hi joerg!), but not high priority nor a real bug.

 The question of supporting dlopen in static binaries is the killer here.
 I think though that the locale can be fixed the same way the pam was (by
 loading all the known locales).

 christos

From: Martin Husemann <martin@duskware.de>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@NetBSD.org, lib-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, ca6c@bitmessage.ch
Subject: Re: lib/53722: Static binaries don't support locales that are
 implemented using shared objects
Date: Mon, 12 Nov 2018 00:40:25 +0100

 On Sun, Nov 11, 2018 at 06:37:00PM -0500, Christos Zoulas wrote:
 > The question of supporting dlopen in static binaries is the killer here.
 > I think though that the locale can be fixed the same way the pam was (by
 > loading all the known locales).

 Or a configurable subset - indeed that sounds like a simple workaround.

 Martin

From: Robert Elz <kre@munnari.OZ.AU>
To: christos@zoulas.com (Christos Zoulas)
Cc: Martin Husemann <martin@duskware.de>, gnats-bugs@NetBSD.org,
        lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
        netbsd-bugs@netbsd.org, ca6c@bitmessage.ch
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 (Christos Zoulas)
     Message-ID:  <20181111233700.48ED117FDA1@rebar.astron.com>

   | 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

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

 On Nov 12,  8:00am, kre@munnari.OZ.AU (Robert Elz) wrote:
 -- Subject: Re: lib/53722: Static binaries don't support locales that are imp

 | 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.

 Nope, there is code too; see /usr/src/lib/libc/citrus/

 | What does using dynamic linking really achieve (aside from that the support
 | is there already, and needed for other stuff.)

 Conserves some memory (there are many locales)... But really not enough to
 make it worth the hassle these days. It is there to allow custom locales
 and to provide code and data isolation for them.

 It is a good GSoC project to make static linking of locales to work. I've
 added it to the list of projects.

 christos

Home	PR Database Search