From: "mark at klomp dot org" <sourceware-bugzilla@sourceware.org>
To: elfutils-devel@sourceware.org
Subject: [Bug general/21008] Incompatible with MUSL libc: error.h and error() not provided
Date: Fri, 27 Aug 2021 17:13:54 +0000 [thread overview]
Message-ID: <bug-21008-10460-GreuxoTlZA@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-21008-10460@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=21008
Mark Wielaard <mark at klomp dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mark at klomp dot org
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from Mark Wielaard <mark at klomp dot org> ---
commit 76c84c137a82a7cacbc69b1696052491b3bb81cb
Author: Saleem Abdulrasool <abdulras@google.com>
Date: Fri Aug 20 20:28:23 2021 +0000
handle libc implementations which do not provide `error.h`
Introduce a configure time check for the presence of `error.h`. In the
case that `error.h` is not available, we can fall back to `err.h`.
Although `err.h` is not a C standard header (it is a BSD extension),
many libc implementations provide. If there are targets which do not
provide an implementation of `err.h`, it would be possible to further
extend the implementation to be more portable.
This resolves bug #21008.
Signed-off-by: Saleem Abdulrasool <abdulras@google.com>
commit 4d6dd0e5ad5c3366cbf701b4fb62b6d91be545f8
Author: Saleem Abdulrasool <abdulras@google.com>
Date: Fri Aug 27 15:51:47 2021 +0000
lib: avoid potential problems with `-fno-common`
This properly homes the fallback function into a translation unit rather
than trying to define an inline common definition for the fallback path.
The intent of the original approach was to actually simply avoid adding
a new source file that is used for the fallback path. However, that may
cause trouble with multiple definitions if the symbol does not get vague
linkage (which itself is not particularly great). This simplifies the
behaviour at the cost of an extra inode.
commit 610623458b7e98ed3e912e4b7ca8050f6ce4c698
Author: Mark Wielaard <mark@klomp.org>
Date: Fri Aug 27 18:47:30 2021 +0200
Add lib/error.c
This new file was supposed to be part of 4d6dd0e5a "lib: avoid potential
problems with `-fno-common`".
Signed-off-by: Mark Wielaard <mark@klomp.org>
--
You are receiving this mail because:
You are on the CC list for the bug.
prev parent reply other threads:[~2021-08-27 17:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-30 20:42 [Bug general/21008] New: " luizluca at gmail dot com
2016-12-30 21:16 ` [Bug general/21008] " luizluca at gmail dot com
2016-12-30 21:29 ` luizluca at gmail dot com
2018-07-04 14:54 ` ross at burtonini dot com
2021-08-27 17:13 ` mark at klomp dot org [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=bug-21008-10460-GreuxoTlZA@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=elfutils-devel@sourceware.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).