Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: libs transition /usr/lib -> /lib questions
Date: Fri, 6 Jan 2012 09:48:59 -0600	[thread overview]
Message-ID: <4F0717EB.7050807@windriver.com> (raw)
In-Reply-To: <201201060029.45032.schnitzeltony@gmx.de>

On 1/5/12 5:29 PM, Andreas Müller wrote:
> Hi
>
> currently some libs are moving from $libdir (/usr/lib) ->  $base_libdir (/lib). I
> have the following questions:
>
> * can sombody explain a bit more what is it for and how the decision is made to
> transit libs? I read the commit messages but still have no idea what this
> enhances / fixes. What is 'not safe' or - I guess the insane.bbclass modification
> deals same issue - 'system recovery'. Is that something I (should) have? :)

The issue is based on the separation of the "root" (/) and "user" (/usr) 
partition.  It is reasonable, and in many cases advisable to breakup the system 
into multiple partitions.  The FHS (and UNIX tradition) support the idea of a 
small root filesystem w/ a /usr partition adding the majority of the 
functionality to the system.  (Note: in OE-Core the 'user' partition is 
equivalent to the exec_prefix, which some distributions make '/' in order to 
flatten the filesystem.  In this case the code will detect root and user are the 
same and do nothing.)

The problem being identified, and resolved is that if a binary exists in the 
root partition, then all of it's support libraries must also exist in the root 
partition.  I.e. "/bin/grep" can't refer to "/usr/lib/libncurses.so".  Because 
during early boot a script may use grep for functionality, but if /usr is not 
yet mounted it will fail.  Detecting this is fairly simple -- correlate the 
libraries required by an executable in the root partition and verify they are 
not requiring anything located in the /usr partition.

Similarly if shell scripts require functionality that only exist in /usr, then 
they may also cause a failure condition if /usr is not yet mounted.  (This of 
course is much harder to detect, which is why this test is only a warning and 
likely to only ever be a warning as there will potentially be a lot of false 
positives.)

When a QA situation is detected there are three common solutions to the problem:

*) Move the required library from the user partition to root

*) Move the binary from the root partition to the user partition

*) Change the options of the binary to no longer require the library in the user 
partition

Each of the above should be evaluated based on the implicit goal that the root 
partition continue to be "small", with the rule of thumb that it needs to 
contain enough to do early boot and mount of the user filesystem -- and 
potentially recovery activities in case of a failure.

(I see Scott answered the question below already..)

--Mark

> * can somebody please take care what I see with meta-oe / obexd:
>
> | ./arm-angstrom-linux-gnueabi-libtool  --tag=CC   --mode=link ccache arm-
> angstrom-linux-gnueabi-gcc  -march=armv7-a -fno-tree-vectorize      -mthumb-
> interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 -mthumb-interwork -mno-
> thumb --sysroot=/home/Superandy/tmp/oe-core-eglibc/sysroots/overo -
> I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/include/glib-2.0 -
> I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/lib/glib-2.0/include   -
> I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/include/dbus-1.0 -
> I/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/usr/lib/dbus-1.0/include -
> D_FILE_OFFSET_BITS=64 -DOBEX_PLUGIN_BUILTIN -
> DPLUGINDIR=\""/usr/lib/obex/plugins"\" -O -fno-omit-frame-pointer -g -
> feliminate-unused-debug-types -pipe -O0 -Wl,--export-dynamic -Wl,-O1 -Wl,--hash-
> style=gnu -Wl,--as-needed -o src/obexd gdbus/mainloop.o gdbus/watch.o
> gdbus/object.o gdbus/polkit.o plugins/bluetooth.o  plugins/filesystem.o
> plugins/opp.o plugins/ftp.o plugins/pbap.o plugins/vcard.o plugins/mas.o
> plugins/irmc.o plugins/syncevolution.o btio/btio.o src/main.o src/plugin.o
> src/log.o src/manager.o src/obex.o src/mimetype.o src/service.o src/transport.o
> src/server.o plugins/phonebook.o plugins/messages.o -ldbus-1 -lpthread -lrt   -
> lglib-2.0 -lopenobex -lbluetooth   -lical -licalss -licalvcal -lpthread -ldl
> | arm-angstrom-linux-gnueabi-libtool: link: cannot find the library
> `/home/Superandy/tmp/oe-core-eglibc/sysroots/overo/lib/libusb-1.0.la' or
> unhandled argument `=/lib/libusb-1.0.la'
> | make[1]: *** [src/obexd] Error 1
>
> libusb-1.0.la still resides in .../sysroots/overo/usr/lib. Maybe it needs
> transition too? If yes: Are there also others which need libtool-lib transition?
>
> Thanks
>
> Andreas
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core




  parent reply	other threads:[~2012-01-06 15:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-05 23:29 libs transition /usr/lib -> /lib questions Andreas Müller
2012-01-06  3:35 ` Scott Garman
2012-01-06 13:33   ` Andreas Müller
2012-01-06 10:48 ` Enrico Scholz
2012-01-06 15:48 ` Mark Hatle [this message]
2012-01-22  0:05   ` Khem Raj
  -- strict thread matches above, loose matches on Subject: below --
2012-01-06 10:09 Martin Jansa
2012-01-06 10:34 ` Koen Kooi
2012-01-06 15:59   ` Mark Hatle
2012-01-06 16:04     ` Chris Larson
2012-01-06 16:12       ` Mark Hatle
2012-01-06 16:16       ` Richard Purdie
2012-01-06 16:43         ` Koen Kooi
2012-01-06 16:51           ` Mark Hatle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F0717EB.7050807@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox