[Buildroot] Bizarre things on the allyespackageconfig build

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Sat May 11 10:31:44 UTC 2013


Dear Yann E. MORIN,

On Sat, 11 May 2013 00:27:39 +0200, Yann E. MORIN wrote:

> > I agree, it's not a problem per se, it's just that 99% of the other
> > packages install their shared libraries with executable permissions, so
> > not having them for a few libraries is a bit strange.
> 
> Yep, I like my filesystems to be tidy, too! :-)

Me too. I also noticed some variations on the permissions of
executables. Most of them have the write permissions, but some do not.


> > Also, to be noted that we keep the .so symbolic link, even though it's
> > generally unneeded at runtime. However, unfortunately, simply removing
> > *.so isn't going to work: some of the .so files are directly the shared
> > libraries.
> > 
> > Examples:
> > 
> > $ ls -l libdvb*
> > -rw-r--r-- 1 thomas thomas 20469 May  9 13:21 libdvbapi.so
> > -rw-r--r-- 1 thomas thomas 13415 May  9 13:21 libdvbcfg.so
> > -rw-r--r-- 1 thomas thomas 52375 May  9 13:21 libdvben50221.so
> > -rw-r--r-- 1 thomas thomas 25523 May  9 13:21 libdvbsec.so
> 
> What we could do is scan the rootfs for shared libs, remove the
> symlinks, and rename the libraries to their SONAME.
> 
> Then, until we get rid of "devel stuff on target", we can recreate the
> simple .so symlinks (if it's not the SONAME).
> 
> Also, keep in mind that symlinks each use an inode, which can become a
> bit cumbersome on size-constrained file systems. (hardlinks do not use
> an inode, however). So, getting rid of the useless symlinks is a net
> win overall.

Interesting, those libdvb*.so libraries don't have a SONAME:

$ readelf -d libdvb*.so | grep SONAME
$

Seems like they might be dlopen()ed plugins and not directly shared
libraries per se.

However, some of those non-executables libraries do have a SONAME:

target/usr/lib$ ls -l libproxychains4.so 
-rw-r--r-- 1 thomas thomas 85619 May  9 17:18 libproxychains4.so
target/usr/lib$ readelf -d libproxychains4.so | grep SONAME
 0x0000000e (SONAME)                     Library soname: [libproxychains4.so]

I'm not sure I like the renaming of libraries to their SONAME, but it's
really a matter of perception. Technically speaking, I agree that it
works.

> I've done a preliminary build with that and no /usr/var symlink, and it
> is not satisfactory to me: for example, cups will install some stuff in
> /tmp :
>     before                          after
>     ----------------------------------------------------------
>     /usr/var/run/cups/certs/        /tmp/cups/certs/
>     /usr/var/cache/cups/rss/        /tmp/cups/rss/
>     /usr/var/spool/cups/tmp/        /tmp/cups/tmp/
> 
> So, because /var/run, /var/spool. and /var/cache are symlinks to /tmp,
> all gets install into /tmp/cups.
> 
> I'm not sure this is good, as /tmp is not guaranteed to survive a
> shutdown, especially since /tmp is a tmpfs in the default skeleton.
> Which causes even further grievance since the mountpoint will hide
> the previous content of /tmp anyway.
> 
> I'll see how to "fix" that.
> 
> Other than that, all the packages you mentionned installing things in
> /usr/var did install in /var, and /usr/var was not created. Which is
> otherwise good news.
> 
> Anyway, that still requires a bit more investigations before I can
> submit that.

Ok. Beware that having /var/run, /var/spool and /var/cache point
to /tmp is a feature that allows the root filesystem to be mounted
read-only, and still have the services working. That's something we
should try to keep working, I believe.

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com



More information about the buildroot mailing list