From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] target-finalize: Also copy .so files if BR2_HAVE_DEVFILES is enabled
Date: Thu, 1 Mar 2012 08:48:31 +0100 [thread overview]
Message-ID: <20120301084831.26403240@skate> (raw)
In-Reply-To: <1330563031-20637-1-git-send-email-arnout@mind.be>
Hello Arnout,
Le Thu, 1 Mar 2012 00:50:31 +0000,
"Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be> a ?crit :
> From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>
>
> If BR2_HAVE_DEVFILES is enabled, target-finalizes copies the static
> libraries from STAGING_DIR to TARGET_DIR. However, there may also
> be .so files that are not present on the target (because only the
> versioned .so.x file is present). In particular, this is the case
> for libc.so. So copy these ones as well.
>
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
I was going to ack the patch, but I have a little comment about it.
Some packages seem to always install the .so symlink, some packages seem
to not install the .so symlink (but most seem to do). So maybe instead
of forcefully copying those .so files back to $(O)/target when
BR2_HAVE_DEVFILES is selected, we should settle on what packages should
do with their .so files in order to have a coherent thing.
See this partial output from a random build (which has
BR2_HAVE_DEVFILES *not* set):
lrwxrwxrwx 1 test test 19 Jan 2 13:08 target/usr/lib/libarchive.so -> libarchive.so.2.8.4
lrwxrwxrwx 1 test test 19 Jan 2 13:08 target/usr/lib/libarchive.so.2 -> libarchive.so.2.8.4
-rwxr-xr-x 1 test test 175012 Jan 2 13:17 target/usr/lib/libarchive.so.2.8.4
lrwxrwxrwx 1 test test 23 Jan 2 13:08 target/usr/lib/libart_lgpl_2.so -> libart_lgpl_2.so.2.3.21
lrwxrwxrwx 1 test test 23 Jan 2 13:08 target/usr/lib/libart_lgpl_2.so.2 -> libart_lgpl_2.so.2.3.21
-rwxr-xr-x 1 test test 86316 Jan 2 13:17 target/usr/lib/libart_lgpl_2.so.2.3.21
lrwxrwxrwx 1 test test 22 Jan 2 13:03 target/usr/lib/libcairo.so -> libcairo.so.2.10800.10
lrwxrwxrwx 1 test test 22 Jan 2 13:03 target/usr/lib/libcairo.so.2 -> libcairo.so.2.10800.10
-rwxr-xr-x 1 test test 210204 Jan 2 13:17 target/usr/lib/libcairo.so.2.10800.10
lrwxrwxrwx 1 test test 19 Jan 2 13:08 target/usr/lib/libconfuse.so -> libconfuse.so.0.0.0
lrwxrwxrwx 1 test test 19 Jan 2 13:08 target/usr/lib/libconfuse.so.0 -> libconfuse.so.0.0.0
-rwxr-xr-x 1 test test 34956 Jan 2 13:17 target/usr/lib/libconfuse.so.0.0.0
And this bizarre case:
-rwxr-xr-x 1 test test 76196 Jan 2 13:17 target/usr/lib/libslang.so
lrwxrwxrwx 1 test test 11 Jan 2 13:15 target/usr/lib/libslang.so.1 -> libslang.so
So maybe all packages *should* always install the .so file (be it a
symbolic link or the libc.so linker script), and then:
* When BR2_HAVE_DEVFILES is not set, we get rid of those .so symbolic
links
* When BR2_HAVE_DEVFILES is set, we keep them
That's just a proposal here, other options would be fine with me as
well. It's just that the fact most packages already install the .so
symlink *and* we re-do it in target-finalize when BR2_HAVE_DEVFILES is
set looks confusing.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2012-03-01 7:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-29 13:34 [Buildroot] uClibc missing symbols (undefined reference to `__fini_array_end') Éric ALBER
2012-03-01 0:27 ` Arnout Vandecappelle
2012-03-01 0:30 ` Arnout Vandecappelle
2012-03-01 0:50 ` [Buildroot] [PATCH] target-finalize: Also copy .so files if BR2_HAVE_DEVFILES is enabled Arnout Vandecappelle
2012-03-01 7:48 ` Thomas Petazzoni [this message]
2012-03-02 21:50 ` Arnout Vandecappelle
2012-03-01 11:12 ` [Buildroot] uClibc missing symbols (undefined reference to `__fini_array_end') Éric ALBER
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=20120301084831.26403240@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/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