svn commit: r268461 - in head: . gnu/lib/libreadline gnu/lib/libreadline/history gnu/lib/libreadline/readline gnu/lib/libreadline/readline/doc gnu/usr.bin/gdb gnu/usr.bin/gdb/gdb gnu/usr.bin/gdb/gd...

[Bruce Evans]

On Wed, 9 Jul 2014, Konstantin Belousov wrote:

> On Wed, Jul 09, 2014 at 11:05:29AM -0700, Adrian Chadd wrote:
>> On 9 July 2014 10:23, Baptiste Daroussin <bapt at freebsd.org> wrote:
>>> On Wed, Jul 09, 2014 at 10:12:27AM -0700, Adrian Chadd wrote:
>>>> Hi,
>>>>
>>>> By doing this you're actually making more work for the really embedded
>>>> people who have size constraints on things.
>>>>
>>>> I dislike privatelib but it at least allows for code sharing where
>>>> before people would just statically link things into binaries.
>>>
>>> do you install gdb on your embedded environnement? because that is the only
>>> user of libreadline.
>>
>> See below.
>>>>
>>>> I've had to actively undo this kind of dumb before in order to get
>>>> things to fit on very small flash root filesystems.
>>>>
>>>> Shared libraries are good. Please stop assuming we have lots of disk
>>>> space and RAM to have duplicates of things floating around.

Shared libraries are not good.  They save a little disk space but cost an
enormous amount of RAM.  E.g.:

FreeBSD-~5.2 i386, statically linked:
   PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
  1101 bde         1  76    0  1392K   780K RUN      0:00  0.00% top

FreeBSD-11 i386, dynamically linked:
   PID USERNAME       THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAN
25085 bde              1  21    0 11260K  2432K STOP    4   0:00   0.00% top

Here dynamic linkage and perhaps other bloat takes 3 times as much RAM (RES)
and 8 times as much virtual memory (SIZE).  For long-running programs, even
more RAM (or swap to the disk that you apparently don't have on embedded
systems), it is likely for more of the shared library virtual memory to
be written to so that it becomes physical.  This might explain the even
larger RAM uses in the following:

FreeBSD-~5.2 i386, statically linked:
   PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
   681 root        1  76    0  1676K  1132K select   0:00  0.00% sshd
   659 root        1  44   r0   848K   536K select   0:00  0.00% ntpd
   688 root        1  76    0  2084K  1796K select   0:00  0.00% sendmail

FreeBSD-11 i386, dynamically linked:
   PID USERNAME       THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAN
25072 bde              1  20    0 17836K  6556K select  1   0:00   0.00% sshd
   693 root             1  20    0 12356K  4168K select  4   0:02   0.00% ntpd
   744 root             1  20    0 12868K  4752K select  0   0:01   0.00% sendma

Here dynamic sshd takes almost 6 times as much RAM; dynamic ntpd almost
8 times as much, but dymamic sendmail takes less than 3 times as much.

The output also shows misformatting of the USERNAME column in newer versions
of FreeBSD (lots of unused whitespace to kill the command name non-whitespace).

However, I would like the option to link any library shared, in case I
want to optimize disk space at the cost of RAM and runtime.

> What Baptiste did is the only correct way to handle the ABI and API
> un-stability issues with the third-party libraries.  The change is
> good if only for this sole reason.  Private libraries still conflict
> with the same library installed by other means, in the single process
> image.

Works even better for libc :-).  Static libraries also insulate from
the latest bloat and security holes.  There main problem is that they
give old security holes instead.

Bruce