GNU bug report logs - #20437
ls links too many dynamic libraries

Previous Next

Package: coreutils;

Reported by: Paul Eggert <eggert <at> cs.ucla.edu>

Date: Mon, 27 Apr 2015 05:31:02 UTC

Severity: normal

Tags: notabug

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 20437 <at> debbugs.gnu.org
Cc: SE-Linux <SELinux <at> tycho.nsa.gov>
Subject: bug#20437: ls links too many dynamic libraries
Date: Mon, 27 Apr 2015 15:02:35 +0100
On 27/04/15 14:12, Pádraig Brady wrote:
> tag 20437 notabug
> close 20437
> stop
> 
> On 27/04/15 06:30, Paul Eggert wrote:
>> Currently GNU 'ls' dynamically links a whole bunch of libraries, libraries like 
>> libpcre and liblzma.  Can we figure out some way to remove the runtime 
>> dependencies on these libraries?  It's better if a core utility like 'ls' avoids 
>> libthis and libthat unless the libraries are vital to its function, which these 
>> shouldn't be.
>>
>> I installed the attached patches to get rid of one unnecessary library, libacl, 
>> on GNU/Linux.  Can we do better and get rid of more dependencies?  Perhaps using 
>> techniques similar to what was used to get rid of libacl?
> 
> As was discussed recently¹ with removing the libmount dependency for df,
> these dependencies are coming from libselinux, and one of the primary
> authors of libselinux was made aware of that issue, so I'm closing
> this here.
> 
> coreutils linking with libselinux are:
> 
>  chcon cp dir install id ls mkdir mkfifo mknod mv runcon stat vdir
> 
> BTW I noticed ldd -v doesn't give complete info,
> and that `readelf -d $(which ls) | grep NEEDED` is better.
> This is wrapped in the lddot² visualizer, and I've attached
> the output from `lddot git/coreutils/src/ls | graph-easy --as png`
> 
> cheers,
> Pádraig.
> 
> ¹ http://lists.gnu.org/archive/html/coreutils/2015-04/msg00011.html
> ² http://jwilk.net/software/lddot

BTW I had a look at whether we could duplicate some getfilecon() logic
internally, but it doesn't seem practical due to mcstransd which
is a daemon that's used to translate the MCS / MLS internal policy
levels into user friendly labels.

I.E. we could duplicate the logic, and remove the lzma and pcre dependencies,
but it seems like too much to be duplicating. Further reductions in deps
might be possible by splitting up libselinux, allowing apps like ls
that just read contexts, to link with the appropriate lib.

cheers,
Pádraig.




This bug report was last modified 10 years and 111 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.