[Toybox] New toy: login
Elie De Brauwer
eliedebrauwer at gmail.com
Sun Apr 29 23:34:40 PDT 2012
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
More information about the Toybox
mailing list