Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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