[Toybox] New toy: login

[Elie De Brauwer]

On Sun, Apr 29, 2012 at 3:13 AM, Rob Landley <rob at landley.net> wrote:
>> Attached is a patch which make login depend on probing crypt.h and
>> shadow.h following the unshare example.  I turned these into two probes,
>> just to keep things a bit more understandable, and i suspect that some
>> future toys might depend on either shadow or crypt.
>
> Um, can we wait to split them until something _does_ need them split?  I
> hate having infrastructure awaiting a user, it tends to accumulate and
> then not fit right if somebody _does_ need it. (Yes, I have seen code
> _preemptively_ bit-rot.)

Fair point, I'll modify my patch to include you comments and post an
update, thanks.


>> Regarding the --as-needed. I can update make.sh to contain something as
>>  -Wl,--as-needed,${REQUIRED_LIBS},--no-as-needed but what would be a
>> sensible way to populate the $REQUIRED_LIBS variable ?
>
> Have each test do:
>
>  REQUIRED_LIBS="$REQUIRED_LIBS,fruitbasket"
>
> And then at the end:
>
>  [ ! -z "$REQUIRED_LIBS" ] &&
>    REQUIRED_LIBS="-Wl,--as-needed$REQUIRED_LIBS,--no-as-needed"
>
> (Note the missing comma before $REQUIRED_LIBS since each addition starts
> with one.)

Thanks for the pointer, I'll have this included as well in my patch.

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

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


-- 
Elie De Brauwer

 1335767680.0