[Toybox] New toy: login

[Rob Landley]

On 04/30/2012 01:34 AM, Elie De Brauwer wrote:
> On Sun, Apr 29, 2012 at 3:13 AM, Rob Landley <rob at landley.net> wrote:
>>> I think that a
>>> toy should actually be able to tell whether or not it requires linking
>>> with a certain library or not, but I don't know/think anything like that
>>> is already foreseen/in place ?
>>
>> In theory, yes.  In practice, this means manually maintaining
>> dependencies, which just invites them to be subtly broken in some
>> combination we never tested. Since the compiler and linker have already
>> _grown_ this support, we might as well have the dependencies determined
>> automatically because that shouldn't break (and if it does it should get
>> fixed upstream).
> 
> Which is exactly the reason why I asked if something was in place
> already, rolling your can always occur, and as a result hitting the
> same wall others have hit before your is included for free.

I remember (back on busybox) a case where "whether or not you needed
-lm" varied between uClibc and glibc. Whole lotta not wanting to go there...

>> Note that this also applies to the contents of lib/lib.c. Instead of
>> working out what to include and what not to include there, I just have
>> this in configure:
>>
>> [ -z "$OPTIMIZE" ] &&
>>  OPTIMIZE="-Os -ffunction-sections -fdata-sections -Wl,--gc-sections"
>>
>> It puts every function and piece of data in its own elf section, and
>> then garbage collects unused sections.
> 
> This as opposed to let's say busybox where every shared function, or
> set of a handful of vaguely related functions are stuffed in their own
> .c/.h combo.

In their defense, they predate linkers growing support for this. And
they hit bugs in it that the glibc/binutils guys still point fingers at
each other about.  (Denys explains in the video.)

> But I agree it's the linkers' job to do linking, I do not
> doubt it can do a better job than myself when it comes to linking,
> let's make use of it.
> 
>>
>> (Denys Vlasenko did a marvelous presentation at CELF 2010 about why this
>> breaks glibc's stdio flushing. I can link to the video if you're curious.)
> 
> Links always welcomed, it's only time which is the scarce resource :).

I wasn't online when I wrote that or I would have. :)

Index of that year's videos:
http://free-electrons.com/blog/elc-2010-videos/

Slides and video of talk in question:
http://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf
http://free-electrons.com/pub/video/2010/elc/elc2010-vlasenko-dead-code.ogv

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.

 1335802829.0