All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCHv3 03/12] toolchain-external: clarify rsync excludes in copy_toolchain_sysroot
Date: Wed, 8 Feb 2017 10:45:24 +0100	[thread overview]
Message-ID: <20170208104524.26ea3b9e@free-electrons.com> (raw)
In-Reply-To: <CAAXf6LVTZqdXdZGcr+ni-Xr+zM05UmNDaFvsDdnE-mpRYua_3g@mail.gmail.com>

Hello,

On Wed, 8 Feb 2017 10:22:14 +0100, Thomas De Schampheleire wrote:

> > With the current CodeSourcery NiosII toolchain, this change have a weird side
> > effect...
> >
> > If you look at "host/opt/ext-toolchain/nios2-linux-gnu/libc/usr/lib/", you will
> > find a directory named "libffi-3.2.1". This directory contain the libffi headers !?
> >
> > ls libffi-3.2.1/include
> > ffi.h  ffitarget.h
> >
> > So this directory is now present in STAGING_DIR:
> > ls staging/usr/lib/libffi-3.2.1
> >
> > I think it's a mistake in the toolchain itself...  
> 
> Yes, I think so too. It is very weird that headers would be placed in
> usr/lib/something. Are they also present elsewhere, like in
> usr/include ?
> 
> In any case, the fact that these files are now present in staging
> should not hurt. Also for target it will not make a difference.
> 
> Also, the fact that they used to be skipped with the original code is
> more of an accident, than actual intention.

Agreed. This is more a bug in the toolchain that anything else. We can
always add a custom toolchain hook to get rid of them. But since they
are only in staging, I don't think it's really worth the effort.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

  reply	other threads:[~2017-02-08  9:45 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-07 21:56 [Buildroot] [PATCHv3 00/12] toolchain: improvements to copy_toolchain_sysroot and copy_toolchain_lib_root Thomas De Schampheleire
2017-02-07 21:56 ` [Buildroot] [PATCHv3 01/12] toolchain-external: reduce nesting in copy_toolchain_sysroot Thomas De Schampheleire
2017-03-01 22:22   ` Thomas Petazzoni
2017-02-07 21:56 ` [Buildroot] [PATCHv3 02/12] toolchain-external: fix broken handling of 'usr/lib/locale' Thomas De Schampheleire
2017-03-01 22:34   ` Thomas Petazzoni
2017-02-07 21:56 ` [Buildroot] [PATCHv3 03/12] toolchain-external: clarify rsync excludes in copy_toolchain_sysroot Thomas De Schampheleire
2017-02-07 23:03   ` Romain Naour
2017-02-08  9:22     ` Thomas De Schampheleire
2017-02-08  9:45       ` Thomas Petazzoni [this message]
2017-02-07 21:56 ` [Buildroot] [PATCHv3 04/12] toolchain-external: handle ld.so fixups centrally Thomas De Schampheleire
2017-02-07 21:56 ` [Buildroot] [PATCHv3 05/12] toolchain helpers: introduce function relpath_prefix Thomas De Schampheleire
2017-02-07 21:56 ` [Buildroot] [PATCHv3 06/12] toolchain-external: cover multilib toolchains with lib/<variant> layout Thomas De Schampheleire
2017-02-07 21:56 ` [Buildroot] [PATCHv3 07/12] toolchain helpers: introduce simplify_symlink Thomas De Schampheleire
2017-02-07 21:56 ` [Buildroot] [PATCHv3 08/12] toolchain-external: simplify previously-broken symbolic links Thomas De Schampheleire
2017-02-07 21:56 ` [Buildroot] [PATCHv3 09/12] toolchain: copy_toolchain_lib_root: remove unused variable LIBDIR Thomas De Schampheleire
2017-02-07 21:56 ` [Buildroot] [PATCHv3 10/12] toolchain: copy_toolchain_lib_root: clarify logic Thomas De Schampheleire
2017-02-07 21:56 ` [Buildroot] [PATCHv3 11/12] toolchain: copy_toolchain_lib_root: clarify input parameter Thomas De Schampheleire
2017-02-07 21:56 ` [Buildroot] [PATCHv3 12/12] toolchain: copy_toolchain_lib_root: copy symlinks instead of recreating them Thomas De Schampheleire
2017-04-05 19:54 ` [Buildroot] [PATCHv3 00/12] toolchain: improvements to copy_toolchain_sysroot and copy_toolchain_lib_root Thomas Petazzoni
2017-04-05 20:15   ` Thomas De Schampheleire
2017-04-06 17:09     ` Thomas Petazzoni
2017-04-06 17:51       ` Thomas De Schampheleire

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=20170208104524.26ea3b9e@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.