* [Bug general/21009] New: Incompatible with MUSL libc: canonicalize_file_name
@ 2016-12-30 20:59 luizluca at gmail dot com
2016-12-30 21:29 ` [Bug general/21009] " luizluca at gmail dot com
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: luizluca at gmail dot com @ 2016-12-30 20:59 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21009
Bug ID: 21009
Summary: Incompatible with MUSL libc: canonicalize_file_name
Product: elfutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: general
Assignee: unassigned at sourceware dot org
Reporter: luizluca at gmail dot com
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
Hello
From bug 21002:
- Since canonicalize_file_name (path) is defined as realpath(path, NULL) that
change seems fine.
However, there seems to be some limitation on realpath:
https://mail.gnome.org/archives/gtk-devel-list/2002-October/msg00197.html
If autoconf checks for it, we could simply define a macro for it when
canonicalize_file_name is not present like:
#ifndef HAVE_canonicalize_file_name
#define canonicalize_file_name(name) realpath(name,NULL)
#endif
This function is used only at:
./libdwfl/find-debuginfo.c:388
./libdwfl/dwfl_build_id_find_elf.c:98
And both include system.h. So, the best place to conditionally define it might
be system.h.
What's the correct approach? change the call or conditionally define a new
macro?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug general/21009] Incompatible with MUSL libc: canonicalize_file_name
2016-12-30 20:59 [Bug general/21009] New: Incompatible with MUSL libc: canonicalize_file_name luizluca at gmail dot com
@ 2016-12-30 21:29 ` luizluca at gmail dot com
2016-12-31 15:36 ` mjw at redhat dot com
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: luizluca at gmail dot com @ 2016-12-30 21:29 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21009
Luiz Angelo Daros de Luca <luizluca at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |21002
Referenced Bugs:
https://sourceware.org/bugzilla/show_bug.cgi?id=21002
[Bug 21002] Incompatible with MUSL libc
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug general/21009] Incompatible with MUSL libc: canonicalize_file_name
2016-12-30 20:59 [Bug general/21009] New: Incompatible with MUSL libc: canonicalize_file_name luizluca at gmail dot com
2016-12-30 21:29 ` [Bug general/21009] " luizluca at gmail dot com
@ 2016-12-31 15:36 ` mjw at redhat dot com
2018-03-05 13:29 ` mark at klomp dot org
2018-03-09 23:20 ` mark at klomp dot org
3 siblings, 0 replies; 5+ messages in thread
From: mjw at redhat dot com @ 2016-12-31 15:36 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21009
Mark Wielaard <mjw at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mjw at redhat dot com
--- Comment #1 from Mark Wielaard <mjw at redhat dot com> ---
(In reply to Luiz Angelo Daros de Luca from comment #0)
> However, there seems to be some limitation on realpath:
>
> https://mail.gnome.org/archives/gtk-devel-list/2002-October/msg00197.html
I assume that refers to this:
BUGS
The POSIX.1-2001 standard version of this function is broken by design,
since it is impossible to determine a suitable size for the output
buffer, resolved_path. According to POSIX.1-2001 a buffer of size
PATH_MAX suffices, but PATH_MAX need not be a defined constant, and may
have to be obtained using pathconf(3). And asking pathconf(3) does not
really help, since, on the one hand POSIX warns that the result of
pathconf(3) may be huge and unsuitable for mallocing memory, and on the
other hand pathconf(3) may return -1 to signify that PATH_MAX is not
bounded. The resolved_path == NULL feature, not standardized in
POSIX.1-2001, but standardized in POSIX.1-2008, allows this design
problem to be avoided.
Even old glibc versions (at least 2.5+) implemented the resolved_path == NULL
feature. So I think we can assume any recent glibc alternative also has this.
> If autoconf checks for it, we could simply define a macro for it when
> canonicalize_file_name is not present like:
>
> #ifndef HAVE_canonicalize_file_name
> #define canonicalize_file_name(name) realpath(name,NULL)
> #endif
>
> This function is used only at:
>
> ./libdwfl/find-debuginfo.c:388
> ./libdwfl/dwfl_build_id_find_elf.c:98
>
> And both include system.h. So, the best place to conditionally define it
> might be system.h.
>
> What's the correct approach? change the call or conditionally define a new
> macro?
I think we can assume everybody uses glibc or a modern alternative that already
implements the resolved_path == NULL feature. So I would simply change the two
callers of canonicalize_file_name (name) to realpath (name, NULL).
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug general/21009] Incompatible with MUSL libc: canonicalize_file_name
2016-12-30 20:59 [Bug general/21009] New: Incompatible with MUSL libc: canonicalize_file_name luizluca at gmail dot com
2016-12-30 21:29 ` [Bug general/21009] " luizluca at gmail dot com
2016-12-31 15:36 ` mjw at redhat dot com
@ 2018-03-05 13:29 ` mark at klomp dot org
2018-03-09 23:20 ` mark at klomp dot org
3 siblings, 0 replies; 5+ messages in thread
From: mark at klomp dot org @ 2018-03-05 13:29 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21009
--- Comment #2 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Mark Wielaard from comment #1)
> I think we can assume everybody uses glibc or a modern alternative that
> already implements the resolved_path == NULL feature. So I would simply
> change the two callers of canonicalize_file_name (name) to realpath (name,
> NULL).
https://sourceware.org/ml/elfutils-devel/2018-q1/msg00066.html
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug general/21009] Incompatible with MUSL libc: canonicalize_file_name
2016-12-30 20:59 [Bug general/21009] New: Incompatible with MUSL libc: canonicalize_file_name luizluca at gmail dot com
` (2 preceding siblings ...)
2018-03-05 13:29 ` mark at klomp dot org
@ 2018-03-09 23:20 ` mark at klomp dot org
3 siblings, 0 replies; 5+ messages in thread
From: mark at klomp dot org @ 2018-03-09 23:20 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21009
Mark Wielaard <mark at klomp dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from Mark Wielaard <mark at klomp dot org> ---
commit 06263dda990be6778a4beb33481cfd39ce60c623
Author: Mark Wielaard <mark@klomp.org>
Date: Mon Mar 5 14:23:14 2018 +0100
libdwfl: Use realpath (name, NULL) instead of canonicalize_file_name
(name).
Some systems apparently don't provide canonicalize_file_name. Since
canonicalize_file_name (path) is defined as realpath(path, NULL) just
use realpath everywhere.
https://sourceware.org/bugzilla/show_bug.cgi?id=21009
Signed-off-by: Mark Wielaard <mark@klomp.org>
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-03-09 23:20 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-30 20:59 [Bug general/21009] New: Incompatible with MUSL libc: canonicalize_file_name luizluca at gmail dot com
2016-12-30 21:29 ` [Bug general/21009] " luizluca at gmail dot com
2016-12-31 15:36 ` mjw at redhat dot com
2018-03-05 13:29 ` mark at klomp dot org
2018-03-09 23:20 ` mark at klomp dot org
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).