From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 4/5] toolchain-external: align library locations in target and staging dir
Date: Mon, 25 Apr 2016 23:15:56 +0200 [thread overview]
Message-ID: <20160425231556.46640d32@free-electrons.com> (raw)
In-Reply-To: <56F843D0.2030202@mind.be>
Hello,
On Sun, 27 Mar 2016 22:34:24 +0200, Arnout Vandecappelle wrote:
> > package/glibc/glibc.mk | 2 +-
> > toolchain/helpers.mk | 57 ++--------------------
> > toolchain/toolchain-external/toolchain-external.mk | 39 ++++-----------
> > 3 files changed, 15 insertions(+), 83 deletions(-)
>
> -65 net lines, that's the kind of patch I like!
Me too!
> > + LIBPATHS=`find $(STAGING_DIR) -follow -name "$${LIB}" 2>/dev/null` ; \
>
> -follow is documented as depracated, use -L instead. But why do we need this?
I've applied after changing -follow to -L. Note that the -L needs to be
*before* $(STAGING_DIR), since the difference between -follow and -L is
that -L only applies to the arguments that *follow* it. And since
$(STAGING_DIR) is a symbolic link, we need -L before it.
> I tried without it and it seems to work just the same. I also don't think the
> error redirect is needed anymore (at least when the -follow is removed).
I've left it as-is for now, those can be handled later if needed.
> > for LIBPATH in $${LIBPATHS} ; do \
> > + DESTDIR=`echo $${LIBPATH} | sed "s,^$(STAGING_DIR)/,," | xargs dirname` ; \
>
> I would have written this as
>
> DESTDIR=`echo $${LIBPATH} | sed "s,^$(STAGING_DIR)/\(.*\)/[^/]*,\1,"` ; \
>
> but perhaps I'm too much of a regexp lover :-)
Yeah, I think I find Thomas DS version easier to understand.
> > + mkdir -p $(TARGET_DIR)/$${DESTDIR}; \
> > while true ; do \
>
> I wonder if the loop is still needed now. As far as I can see, the idea of
> this loop was to make sure that the library pointed to was also copied. But
> since we now copy everything even if it is not in the expected lib path, it
> shouldn't be needed anymore. Except if the library pointed to doesn't match the
> glob pattern we are searching for... Anyway, that's something for a separate patch.
The library pointed to doesn't always match the glob pattern. Let's
take the case of uClibc. The pattern for the C library itself is:
libc.so.*
But for uClibc, we have:
libc.so.1 -> libuClibc-1.0.12.so
and libuClibc-1.0.12.so doesn't match libc.so.*.
> > + $(Q)if test -z "$(BR2_STATIC_LIBS)" ; then \
>
> This can now be converted into a make condition instead of a shell condition,
> which simplifies the logic even more. Well, actually, it could have been a make
> condition from the start because all of the above doesn't do anything except set
> some variables...
Before the previous patch, the installation of gdbserver was done as
part of the same variable, so that's why a make condition was not used.
But I've converted it to a make condition, now that it is possible.
Thanks for the review!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2016-04-25 21:15 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-12 19:20 [Buildroot] [PATCH 0/5] Align library locations in target and staging Thomas De Schampheleire
2016-02-12 19:20 ` [Buildroot] [PATCH 1/5] toolchain-external: blackfin: install FDPIC libraries also to staging Thomas De Schampheleire
2016-03-22 21:48 ` Romain Naour
2016-03-27 16:20 ` Arnout Vandecappelle
2016-04-25 21:00 ` Thomas Petazzoni
2016-02-12 19:20 ` [Buildroot] [PATCH 2/5] toolchain-external: remove unused calculation of ARCH_SUBDIR Thomas De Schampheleire
2016-03-22 21:53 ` Romain Naour
2016-03-27 20:34 ` Arnout Vandecappelle
2016-03-27 23:10 ` Arnout Vandecappelle
2016-04-21 21:30 ` Thomas Petazzoni
2016-02-12 19:20 ` [Buildroot] [PATCH 3/5] toolchain-external: extract installation of gdbserver to separate define Thomas De Schampheleire
2016-03-22 22:04 ` Romain Naour
2016-03-27 16:43 ` Arnout Vandecappelle
2016-04-25 21:02 ` Thomas Petazzoni
2016-02-12 19:20 ` [Buildroot] [PATCH 4/5] toolchain-external: align library locations in target and staging dir Thomas De Schampheleire
2016-03-22 22:53 ` Romain Naour
2016-03-27 20:34 ` Arnout Vandecappelle
2016-04-25 21:15 ` Thomas Petazzoni [this message]
2016-04-26 11:32 ` Thomas De Schampheleire
2016-04-25 21:08 ` Thomas Petazzoni
2016-02-12 19:20 ` [Buildroot] [PATCH 5/5] toolchain-external: unify LIB_EXTERNAL_LIBS and USR_LIB_EXTERNAL_LIBS Thomas De Schampheleire
2016-03-22 22:58 ` Romain Naour
2016-03-27 20:36 ` Arnout Vandecappelle
2016-04-25 21:16 ` Thomas Petazzoni
2016-03-10 8:02 ` [Buildroot] [PATCH 0/5] Align library locations in target and staging Thomas De Schampheleire
2016-03-27 20:39 ` Arnout Vandecappelle
2016-03-27 20:52 ` Romain Naour
2016-03-27 23:08 ` Arnout Vandecappelle
2016-03-29 14:21 ` Thomas De Schampheleire
2016-03-29 14:33 ` Arnout Vandecappelle
2016-04-25 21:17 ` Thomas Petazzoni
2016-04-26 7:50 ` Thomas De Schampheleire
2016-04-26 8:28 ` Thomas Petazzoni
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=20160425231556.46640d32@free-electrons.com \
--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