From: Ladislav Michl <oss-lists@triops.cz>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] [PATCH 2/2] beep: version bump 1.3 -> 1.4.12
Date: Thu, 2 May 2024 12:54:21 +0200 [thread overview]
Message-ID: <ZjNw3VmNCgGpJwsq@lenoch> (raw)
In-Reply-To: <ZjNfBuzqSlvY6uoD@pengutronix.de>
On Thu, May 02, 2024 at 11:38:14AM +0200, Michael Olbrich wrote:
> On Wed, Apr 24, 2024 at 05:33:22PM +0200, Ladislav Michl wrote:
> > On Tue, Apr 23, 2024 at 07:36:52AM +0200, Ladislav Michl wrote:
> > > Move package to a new upstream at https://github.com/spkr-beep/beep/
> >
> > For v5te I needed to add LDFLAGS=-latomic to satisfy undefined reference:
> > arm-v5te-linux-gnueabi-gcc -Wl,-Map=beep.map,--cref -fasynchronous-unwind-tables -fanalyzer -fstack-protector-strong -fstack-clash-protection -fsanitize=undefined -save-temps=obj -O2 -g -std=gnu99 -pedantic -Wall -Wextra -Werror -Wno-padded -Wno-format-nonliteral -o beep beep-log.o beep-main.o beep-library.o beep-usage.o beep-drivers.o beep-driver-console.o beep-driver-evdev.o
> > /opt/OSELAS.Toolchain-2023.07.1/arm-v5te-linux-gnueabi/gcc-13.2.1-glibc-2.37-binutils-2.40-kernel-6.3.6-sanitized/lib/gcc/arm-v5te-linux-gnueabi/13.2.1/../../../../arm-v5te-linux-gnueabi/bin/ld: /opt/OSELAS.Toolchain-2023.07.1/arm-v5te-linux-gnueabi/gcc-13.2.1-glibc-2.37-binutils-2.40-kernel-6.3.6-sanitized/lib/gcc/arm-v5te-linux-gnueabi/13.2.1/../../../../arm-v5te-linux-gnueabi/lib/libubsan.so: undefined reference to `__atomic_compare_exchange_8'
> > /opt/OSELAS.Toolchain-2023.07.1/arm-v5te-linux-gnueabi/gcc-13.2.1-glibc-2.37-binutils-2.40-kernel-6.3.6-sanitized/lib/gcc/arm-v5te-linux-gnueabi/13.2.1/../../../../arm-v5te-linux-gnueabi/bin/ld: /opt/OSELAS.Toolchain-2023.07.1/arm-v5te-linux-gnueabi/gcc-13.2.1-glibc-2.37-binutils-2.40-kernel-6.3.6-sanitized/lib/gcc/arm-v5te-linux-gnueabi/13.2.1/../../../../arm-v5te-linux-gnueabi/lib/libubsan.so: undefined reference to `__atomic_load_8'
> > collect2: error: ld returned 1 exit status
> >
> > I can see haproxy and dhcp packages are adding target flags based on
> > selected architecture. Is it to way to follow here?
>
> Yes, please handle it like that. If it's missing for other architectures
> (ppc is a possibility here), I'll fix it when it fails in my tests.
I already sent v2 with different approach. Problems boils down to beep's
GNUMakefile trying to figure out whenever compiler supports various
sanitizers flags, but fails to figure out, that it comes at price linking
with sanitizer libraries on some architectures. V2 solves that by removing
all those checks, so external libraries are no longer needed.
ladis
next prev parent reply other threads:[~2024-05-02 10:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-23 5:36 [ptxdist] [PATCH 1/2] Revert "beep: move to staging" Ladislav Michl
2024-04-23 5:36 ` [ptxdist] [PATCH 2/2] beep: version bump 1.3 -> 1.4.12 Ladislav Michl
2024-04-24 15:33 ` Ladislav Michl
2024-05-02 9:38 ` Michael Olbrich
2024-05-02 10:54 ` Ladislav Michl [this message]
2024-05-12 13:16 ` [ptxdist] [APPLIED] Revert "beep: move to staging" Michael Olbrich
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=ZjNw3VmNCgGpJwsq@lenoch \
--to=oss-lists@triops.cz \
--cc=ptxdist@pengutronix.de \
/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