From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/2] Makefile: don't recreate staging symlink if it exists
Date: Tue, 18 Feb 2020 16:40:03 +0100 [thread overview]
Message-ID: <20200218164003.21afcd94@windsurf> (raw)
In-Reply-To: <20200218150101.22274-2-patrickdepinguin@gmail.com>
Hello,
On Tue, 18 Feb 2020 16:01:00 +0100
Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote:
> From: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
>
> Create the staging symlink the same way as the host symlink. This means
> using a make dependency rather than recreating it every time.
>
> In coreutils versions below 8.27, re-creation of symbolic links was not
> atomic. This means that there is a period in time where the existing link is
> removed, before the new one is created. In coreutils 8.27 this was fixed,
> see [1]. Note that CentOS 7 ships with coreutils 8.22.
>
> In the following scenario, this is a problem:
>
> - an application is compiled using the sysroot prepared by Buildroot and
> links against Xenomai userspace libraries, but its build process is steered
> from outside of Buildroot
> - to know the correct flags, the application makefile uses the 'xeno-config'
> file to request them, and passes DESTDIR=/buildroot/output/staging
> - the xeno-config responds with flags based on the path
> '/buildroot/output/staging/...'
> - while the application build is ongoing, a 'make' happens in Buildroot,
> causing the 'staging' symlink to be recreated (even though it already
> existed)
> - when exactly at this time, the application calls the compiler with -I
> flags pointing to output/staging, the build fails with:
>
> -I/buildroot/output/staging/usr/include/xenomai/mercury: Error: ^ is not a directory
> -I/buildroot/output/staging/usr/include/xenomai: Error: ^ is not a directory
> -I/buildroot/output/staging/usr/include/xenomai/xenomai: Error: ^ is not a directory
> -I/buildroot/output/staging/usr/include/xenomai/psos: Error: ^ is not a directory
> Failed: ** ^ *
>
> Work around this problem by only creating the staging symlink once, similar
> to how the host symlink (if any) is created.
>
> See also commit d0f4f95e390bcb1c953efa125f5277a8a235396e which changed the
> way these symlinks are made. The reasoning in this commit is to move away
> from the 'dirs' target.
>
> [1] https://github.com/coreutils/coreutils/commit/376967889ed7ed561e46ff6d88a66779db62737a
Wow, thanks for the investigation and detailed commit log. Quite crazy
stuff.
The question that comes to mind is: why are you building something
against the Buildroot toolchain/sysroot, before the Buildroot build has
completed ?
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2020-02-18 15:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-18 15:00 [Buildroot] [PATCH 1/2] Makefile: use HOST_DIR_SYMLINK instead of hardcoding Thomas De Schampheleire
2020-02-18 15:01 ` [Buildroot] [PATCH 2/2] Makefile: don't recreate staging symlink if it exists Thomas De Schampheleire
2020-02-18 15:40 ` Thomas Petazzoni [this message]
2020-02-18 17:59 ` Thomas De Schampheleire
2020-02-18 18:44 ` Thomas Petazzoni
2020-02-19 19:15 ` [Buildroot] [PATCH 1/2] Makefile: use HOST_DIR_SYMLINK instead of hardcoding 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=20200218164003.21afcd94@windsurf \
--to=thomas.petazzoni@bootlin.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.