From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Cc: buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 1/1] package/xz: fix musl static build
Date: Wed, 24 Jul 2024 18:33:54 +0200 [thread overview]
Message-ID: <20240724183354.71cb212b@windsurf> (raw)
In-Reply-To: <20240723215041.771843-1-fontaine.fabrice@gmail.com>
On Tue, 23 Jul 2024 23:50:41 +0200
Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote:
> For an unknown reason, runnning autoreconf is needed to avoid the
> following static build failure on musl which is raised because LDFLAGS
> (which contains -static) is not passed:
>
> /home/autobuild/autobuild/instance-16/output-1/host/lib/gcc/armeb-buildroot-linux-musleabi/13.3.0/../../../../armeb-buildroot-linux-musleabi/bin/ld: /home/autobuild/autobuild/instance-16/output-1/host/lib/gcc/armeb-buildroot-linux-musleabi/13.3.0/libgcc.a(_dvmd_lnx.o): in function `__aeabi_idiv0':
> /home/autobuild/autobuild/instance-16/output-1/build/host-gcc-final-13.3.0/build/armeb-buildroot-linux-musleabi/libgcc/../../../libgcc/config/arm/lib1funcs.S:1499:(.text+0x8): undefined reference to `raise'
>
> This build failure is raised by autobuilders since bump to version 5.6.2
> in commit d1d77eb274761d1f2d24ee4b55a374e917c67a8e but it can also be
> reproduced on version 5.4.7 (but not on 5.4.6). There is probably an
> issue with these two official autotools tarballs which have been
> released the same day (on May 29 2024).
>
> Fixes: 40240ac30afc4c6af765794f38e6815162ca61fa
> - http://autobuild.buildroot.org/results/344813b202644a23c166920aa7e861ebf408536b
>
> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> ---
> package/xz/xz.mk | 2 ++
> 1 file changed, 2 insertions(+)
Thanks for the investigation. However, I'd like to have a little bit
better understanding than "unknown reason". Could you compare the
build/link command lines used by xz without/with the AUTORECONF = YES,
to see what's different?
What puzzles me is that the build failures are related to libgcc.a
missing some symbols. So do we have a xz issue here, or do we have an
actual host-gcc-final issue that somehow gets worked-around by doing
XZ_AUTORECONF = YES ? That is what worries me about merging this fix
without a slightly better understanding of what's going on.
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2024-07-24 16:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-23 21:50 [Buildroot] [PATCH 1/1] package/xz: fix musl static build Fabrice Fontaine
2024-07-24 16:33 ` Thomas Petazzoni via buildroot [this message]
2024-07-24 18:02 ` Fabrice Fontaine
2024-08-02 18:08 ` Thomas Petazzoni via buildroot
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=20240724183354.71cb212b@windsurf \
--to=buildroot@buildroot.org \
--cc=fontaine.fabrice@gmail.com \
--cc=thomas.petazzoni@bootlin.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox