From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/2] toolchain/helper: don't follow symlinks when copying libs to target
Date: Mon, 30 May 2016 17:53:17 +0200 [thread overview]
Message-ID: <20160530155317.GA3567@free.fr> (raw)
In-Reply-To: <95e5afb7-0922-92cd-8ef7-7807f833b6f6@mind.be>
Arnout, All,
On 2016-05-30 00:33 +0200, Arnout Vandecappelle spake thusly:
> On 05/29/16 23:12, Yann E. MORIN wrote:
> > Thomas DS, All,
> >
> > On 2016-05-29 20:54 +0200, Thomas De Schampheleire spake thusly:
> [snip]
> >> While the trailing slash is indeed a fine solution, it is kind of dirty.
> >> I wonder if -H would do the trick too:
> > [--SNIP--]
> >> It should make sure that only STAGING_DIR is resolved, not any other
> >> symbolic link encountered.
> >
> > Well, appending a slash is a sure mean to make it sure the target of the
> > symlink (if it is a symlink to start with) is entered. I don't see where
> > it is dirty.
>
> I should have realized this before, but: when is $(STAGING_DIR) ever a symlink?
> It's defined as $(HOST_DIR)/usr/$(GNU_TARGET_NAME)/sysroot and it's explicitly
> mkdir'ed in the Makefile. It's not a symlink. $(O)/staging is a symlink, but
> that's not what's used here.
>
> That makes me think there must have been a different reason why Thomas added
> the -L. Thomas originally wrote:
>
> I used -follow just to make sure that STAGING_DIR is entered. It seems
> to work without just because STAGING_DIR happens to be defined with a
> trailing slash, in which case its contents are evaluated anyhow by
> find. I considered this dependency too fragile and wanted it to work
> even if someone optimizes away the trailing slash. Another solution
> would be to add a trailing slash manually as $(STAGING_DIR)/ but -L is
> much cleaner.
>
> Note that there never has been a trailing / in STAGING_DIR.
>
> Thomas, any idea what is going on here?
>
> I did a quick try with just removing -L and it seems to work fine.
>
>
> >
> > Yes, -H does the job, too. But I think it is better that we append a
> > slash: it makes it explicit we want to treat it as a directory, not a
> > potential symlink.
> >
> > However, why would we need to handle the symlink case, to begin with? We
> > are controlling the variable passed in this case and it points to a copy
> > of the sysroot we did make. I.e. that variable is not provided by the
> > user; it is always filled by our infra.
>
> Yann, did you mean the same thing as I described above?
Basically, yes.
Regards,
Yann E. MORIN.
> Regards,
> Arnout
>
> >
> > Surely, if we really, really, like really-really, want to make it
> > explicit we want the directory pointed-to by the symlink, then, we
> > should probably do:
> >
> > find $$(readlink -f $(STAGING_DIR)) -name blabla
> >
> > Regards,
> > Yann E. MORIN.
> >
>
>
> --
> Arnout Vandecappelle arnout at mind be
> Senior Embedded Software Architect +32-16-286500
> Essensium/Mind http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
prev parent reply other threads:[~2016-05-30 15:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-29 15:17 [Buildroot] [PATCH 0/2] toolchain/external: fix installing libs to target (branch yem-ext-toolchain-fixes) Yann E. MORIN
2016-05-29 15:17 ` [Buildroot] [PATCH 1/2] toolchain/external: fix arch-subdir Yann E. MORIN
2016-05-30 21:01 ` Arnout Vandecappelle
2016-05-30 21:53 ` Yann E. MORIN
2016-05-29 15:17 ` [Buildroot] [PATCH 2/2] toolchain/helper: don't follow symlinks when copying libs to target Yann E. MORIN
2016-05-29 18:54 ` Thomas De Schampheleire
2016-05-29 21:12 ` Yann E. MORIN
2016-05-29 22:33 ` Arnout Vandecappelle
2016-05-30 6:58 ` Thomas De Schampheleire
2016-05-30 7:03 ` Peter Korsgaard
2016-05-30 20:06 ` Arnout Vandecappelle
2016-05-30 20:53 ` Peter Korsgaard
2016-05-30 15:53 ` Yann E. MORIN [this message]
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=20160530155317.GA3567@free.fr \
--to=yann.morin.1998@free.fr \
--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