[Bug 217291] New: librt empty, man pages should not tell users to link with -lrt

[Bug 217291] New: librt empty, man pages should not tell users to link with -lrt

[bugzilla-daemon]

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.

[Bug 217291] librt empty, man pages should not tell users to link with -lrt

[bugzilla-daemon]

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.

[Bug 217291] librt empty, man pages should not tell users to link with -lrt

[bugzilla-daemon]

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.

[Bug 217291] librt empty, man pages should not tell users to link with -lrt

[bugzilla-daemon]

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.