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

Adrian Chadd adrian at freebsd.org
Wed Jul 9 19:09:04 UTC 2014


On 9 July 2014 11:27, Konstantin Belousov <kostikbel at gmail.com> 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.
>> >
>> > 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.

Alas, if only remote MIPS gdb for (at least kernel) worked.. :-)



-a


More information about the svn-src-head mailing list