[Toybox] New toy: login

[Rob Landley]

On 04/28/2012 08:35 AM, Elie De Brauwer wrote:
> On 04/25/2012 04:18 AM, Rob Landley wrote:
>> Specifically, you add three new headers, one of which is in susv4
>> (syslog.h) and two of which aren't (crypt.h and shadow.h).
>>
>> This implies we should have another config time probe in
>> scripts/genconfig.sh to go with the unshare() probe, setting some kind
>> of symbol (TOYBOX_CSHADOW) that login can depend on the way unshare does
>> now. We can do one probe for both crypt and shadow, I'm not sure making
>> shadow configurable in 2012 buys us much. World readable /etc/passwd is
>> obsolete.
>>
>> Probably also good to make the new --as-needed stanza be conditionally
>> added to some sort of $AS_NEEDED evironment variable, and used through
>> that on the compiler command line.  (I dunno what the compiler does on
>> systems that haven't got -lcrypt, I thin even with --as-needed that's a
>> build break if the library isn't found. I know glibc and uClibc can
>> provide this, not sure about musl, who knows about macosx and I still
>> haven't got a bionic test environment set up. So yeah, not in susv4 or
>> implies a probe when it comes to headers.)
>>
> 
> 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.)

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

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

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.

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

> my 2 cents
> E.

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.

 1335661992.0