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

[Konstantin Belousov]

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.
> >
> > Facts:
> > Before
> > gdb + kgdb + gdbtui + libreadline.so.8 + libhistory.so.8 = 8976 k
> > After
> > gdb + kgdb + gdbtui = 8973 k
> >
> > I don't think I have damaged too much your embedded system am I wrong?
> >
> > Do I miss something?
> >
> > (Yes I have checked that before turning into an internallib given my first
> > approach was to turn into a privatelib.
> 
> Sure, except for the people who have done things like rolled local
> configuration/management telnet interfaces for these things. They're
> also using libreadline (and things like the cisco UI library.)
> 
> And yeah, I do install gdb in there from time to time. Code sometimes
> needs debugging. :-)
> 

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.

That said, if you do development directly on the tiny platforms, the
remote gdb server is probably better solution than the local gdb.
Also, WITH_SHARED_TOOLCHAIN probably would give you much bigger
savings both in disk space and used memory than libreadline and
libgnuregex.  I just abandoned a hope to flip this knob.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20140709/ebab2338/attachment.sig>