* [Bug 217291] New: librt empty, man pages should not tell users to link with -lrt
@ 2023-04-03 8:23 bugzilla-daemon
2023-04-05 0:52 ` [Bug 217291] " bugzilla-daemon
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: bugzilla-daemon @ 2023-04-03 8:23 UTC (permalink / raw
To: linux-man
https://bugzilla.kernel.org/show_bug.cgi?id=217291
Bug ID: 217291
Summary: librt empty, man pages should not tell users to link
with -lrt
Product: Documentation
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: low
Priority: P1
Component: man-pages
Assignee: documentation_man-pages@kernel-bugs.osdl.org
Reporter: blomqvist.janne@gmail.com
Regression: No
Nowadays librt.a is empty and librt.so is an empty placeholder, and everything
has moved to libc proper. Similar to what was done with clock_gettime() and
friends for glibc 2.17. Man pages should have similar language as for
clock_gettime that one no longer needs to link with -lrt except for old glibc
versions.
Looking at the output of git grep -F -e '-lrt' in the man-pages repo it seems
the following man pages need fixing:
man2/timer_create.2 - Moved to libc in glibc 2.34
man2/timer_delete.2 - Same
man2/timer_getoverrun.2 - Same
man2/timer_settime.2 - Same
man3/aio_cancel.3 - Same
man3/aio_error.3 - Same
man3/aio_fsync.3 - Same
man3/aio_init.3 - Same
man3/aio_read.3 - Same
man3/aio_return.3 - Same
man3/aio_suspend.3 - Same
man3/aio_write.3 - Same
man3/intro.3 - No need to mention obsolete librt?
man3/lio_listio.3 - Moved to libc in glibc 2.34
man3/mq_close.3 - Same
man3/mq_getattr.3 - Same
man3/mq_notify.3 - Same
man3/mq_open.3 - Same
man3/mq_receive.3 - Same
man3/mq_send.3 - Same
man3/mq_unlink.3 - Same
man3/pthread_getcpuclockid.3 - Remove -lrt from example comment
man3/shm_open.3 - Moved to libc in glibc 2.34
man7/mq_overview.7 - Update to reflect that -lrt needed only for
glibc < 2.34
man7/shm_overview.7 - Same
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug 217291] librt empty, man pages should not tell users to link with -lrt
2023-04-03 8:23 [Bug 217291] New: librt empty, man pages should not tell users to link with -lrt bugzilla-daemon
@ 2023-04-05 0:52 ` bugzilla-daemon
2023-04-05 5:02 ` bugzilla-daemon
2023-04-07 23:28 ` bugzilla-daemon
2 siblings, 0 replies; 4+ messages in thread
From: bugzilla-daemon @ 2023-04-05 0:52 UTC (permalink / raw
To: linux-man
https://bugzilla.kernel.org/show_bug.cgi?id=217291
Sam James (sam@gentoo.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sam@gentoo.org
--- Comment #1 from Sam James (sam@gentoo.org) ---
It depends on one's libc (non-glibc implementations are free to need it still)
rather than being obsolete altogether.
Ultimately, a configure test is needed.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug 217291] librt empty, man pages should not tell users to link with -lrt
2023-04-03 8:23 [Bug 217291] New: librt empty, man pages should not tell users to link with -lrt bugzilla-daemon
2023-04-05 0:52 ` [Bug 217291] " bugzilla-daemon
@ 2023-04-05 5:02 ` bugzilla-daemon
2023-04-07 23:28 ` bugzilla-daemon
2 siblings, 0 replies; 4+ messages in thread
From: bugzilla-daemon @ 2023-04-05 5:02 UTC (permalink / raw
To: linux-man
https://bugzilla.kernel.org/show_bug.cgi?id=217291
--- Comment #2 from Janne Blomqvist (blomqvist.janne@gmail.com) ---
(In reply to Sam James from comment #1)
> It depends on one's libc (non-glibc implementations are free to need it
> still) rather than being obsolete altogether.
>
> Ultimately, a configure test is needed.
I'm not sure the man-pages project really concerns itself with non-glibc
libc's. Of course you're right that a project that wants to be portable to
multiple libc's will need configure tests (or equivalent). But that doesn't
mean that a project that aims to document how to use glibc shouldn't tell users
how to use it.
My suggestion is that the man pages I mentioned above should have languages
like clock_gettime and friends already have. That is, from
https://www.man7.org/linux/man-pages/man3/clock_gettime.3.html :
Link with -lrt (only for glibc versions before 2.17).
Or in the current repo:
.SH LIBRARY
Standard C library
.RI ( libc ", " \-lc ),
since glibc 2.17
.PP
Before glibc 2.17,
Real-time library
.RI ( librt ", " \-lrt )
(Not sure why one needs to explicitly tell to link with libc (-lc) and thus how
this is an improvement over the older version published on the web page (and in
most Linux distros man pages), but I digress)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug 217291] librt empty, man pages should not tell users to link with -lrt
2023-04-03 8:23 [Bug 217291] New: librt empty, man pages should not tell users to link with -lrt bugzilla-daemon
2023-04-05 0:52 ` [Bug 217291] " bugzilla-daemon
2023-04-05 5:02 ` bugzilla-daemon
@ 2023-04-07 23:28 ` bugzilla-daemon
2 siblings, 0 replies; 4+ messages in thread
From: bugzilla-daemon @ 2023-04-07 23:28 UTC (permalink / raw
To: linux-man
https://bugzilla.kernel.org/show_bug.cgi?id=217291
Alejandro Colomar (alx@kernel.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |alx@kernel.org
Resolution|--- |INVALID
--- Comment #3 from Alejandro Colomar (alx@kernel.org) ---
On 4/5/23 07:02, bugzilla-daemon@kernel.org wrote:
> I'm not sure the man-pages project really concerns itself with non-glibc
> libc's.
It does.
> Of course you're right that a project that wants to be portable to
> multiple libc's will need configure tests (or equivalent). But that doesn't
> mean that a project that aims to document how to use glibc shouldn't tell
> users
> how to use it.
POSIX says that we should use -lrt, so I document that. If glibc makes it
easier by putting everything in -lc, that's sugar for us, but unless the
entire world follows glibc in that, or at least POSIX, I prefer to document
POSIX.
>
> My suggestion is that the man pages I mentioned above should have languages
> like clock_gettime and friends already have. That is, from
> https://www.man7.org/linux/man-pages/man3/clock_gettime.3.html :
I should rather fix clock_gettime(3) to show only what POSIX requires, which
is -lrt. I just didn't find the time to compare all the pages with POSIX.
What's the benefit of removing -lrt?
>
> Link with -lrt (only for glibc versions before 2.17).
>
> Or in the current repo:
>
> .SH LIBRARY
> Standard C library
> .RI ( libc ", " \-lc ),
> since glibc 2.17
> .PP
> Before glibc 2.17,
> Real-time library
> .RI ( librt ", " \-lrt )
>
> (Not sure why one needs to explicitly tell to link with libc (-lc) and thus
> how
> this is an improvement over the older version published on the web page (and
> in
> most Linux distros man pages), but I digress)
Consistency. If you see -lc, you know where it is. If you don't see it,
then there are two options: either it is in libc, or the author forgot to
document where it is.
Also, while it's often unnecessary to specify -lc, it may in some corner cases
be
necessary, so I prefer specifying it.
Thanks for reporting! However, I don't agree with the report :)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-04-07 23:28 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-04-03 8:23 [Bug 217291] New: librt empty, man pages should not tell users to link with -lrt bugzilla-daemon
2023-04-05 0:52 ` [Bug 217291] " bugzilla-daemon
2023-04-05 5:02 ` bugzilla-daemon
2023-04-07 23:28 ` bugzilla-daemon
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).