From: Steven Rostedt <rostedt@goodmis.org>
To: CaoRuichuang <create0818@163.com>
Cc: linux-trace-devel@vger.kernel.org, tz.stoyanov@gmail.com
Subject: Re: [PATCH v2] libtraceevent: avoid racing recursive builds of both libraries
Date: Fri, 29 May 2026 14:07:30 -0400 [thread overview]
Message-ID: <20260529140730.3ea1859b@fedora> (raw)
In-Reply-To: <20260406062855.58598-1-create0818@163.com>
On Mon, 6 Apr 2026 14:28:55 +0800
CaoRuichuang <create0818@163.com> wrote:
Sorry for the late reply, I've been quite busy on the kernel side of things.
> A top-level parallel build currently starts separate recursive makes for
> libtraceevent.a and libtraceevent.so. Both sub-makes rebuild the same
> object files in the same output directory, which can corrupt the .o
> files and make the final link fail with file format errors.
>
> The src/ Makefile already builds libtraceevent.so as part of the
> libtraceevent.a target. Reflect that at the top level too by making the
> shared library target depend on the static library target, so parallel
> requests for either or both libraries funnel through a single recursive
> make.
>
> This fixes repeated `make -j8`, `make -j8 libs`, and
> `make -j8 libtraceevent.a libtraceevent.so` failures in a Linux VM,
> where the unfixed tree reproduces the race within a few runs.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217428
> Signed-off-by: CaoRuichuang <create0818@163.com>
> ---
> Makefile | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index e1a10a0..6649303 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -211,8 +211,7 @@ libs: libtraceevent.a libtraceevent.so
> $(LIBTRACEEVENT_STATIC): force
> $(Q)$(call descend,$(src)/src,$@)
>
> -$(LIBTRACEEVENT_SHARED): force
> - $(Q)$(call descend,$(src)/src,libtraceevent.so)
> +$(LIBTRACEEVENT_SHARED): $(LIBTRACEEVENT_STATIC)
As you state in the change log, "Makefile already builds
libtraceevent.so as part of the libtraceevent.a target", wouldn't that
mean the above should be:
$(LIBTRACEEVENT_STATIC): $(LIBTRACEEVENT_SHARED)
$(LIBTRACEEVENT_SHARED): force
$(Q)$(call descend,$(src)/src,libtraceevent.so)
??
BTW, thanks for working on this. Sorry I couldn't get to it earlier.
-- Steve
>
> $(bdir)/libtraceevent.so: $(bdir)/libtraceevent.so.$(EP_VERSION)
> @ln -sf $(<F) $@
next prev parent reply other threads:[~2026-05-29 18:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-05 22:21 [PATCH] libtraceevent: avoid racing recursive builds of both libraries CaoRuichuang
2026-04-06 6:28 ` [PATCH v2] " CaoRuichuang
2026-05-29 18:07 ` Steven Rostedt [this message]
2026-06-01 8:20 ` [PATCH v3] " Cao Ruichuang
2026-06-01 14:03 ` Steven Rostedt
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=20260529140730.3ea1859b@fedora \
--to=rostedt@goodmis.org \
--cc=create0818@163.com \
--cc=linux-trace-devel@vger.kernel.org \
--cc=tz.stoyanov@gmail.com \
/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.