public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx.manpages@gmail.com>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: linux-man@vger.kernel.org
Subject: Re: [PATCH v3 05/13] ldconfig.8: Revise and update for glibc 2.32
Date: Fri, 6 Jan 2023 02:21:27 +0100	[thread overview]
Message-ID: <2ef7c0b8-978e-7bc0-d5b9-88ea9348a677@gmail.com> (raw)
In-Reply-To: <20230105225246.uid2pwwivc6testz@illithid>


[-- Attachment #1.1: Type: text/plain, Size: 3094 bytes --]

Hi Branden,

On 1/5/23 23:52, G. Branden Robinson wrote:

> * Comment out multiple paragraphs discussing libc4 and libc5 shared
>    library support.  It was removed upstream in July; annotate commit.


[...]

> @@ -50,50 +52,57 @@ and
>   .I /usr/lib64
>   are used for 64-bit libraries.
>   .PP
> -The cache is used by the run-time linker,
> +It also maintains a cache
> +used by the run-time linker,
>   .I ld.so
>   or
>   .IR ld\-linux.so .
>   .B \%ldconfig
>   checks the header and filenames of the libraries it encounters when
>   determining which versions should have their links updated.
> -.PP
> -.B \%ldconfig
> -will attempt to deduce the type of ELF libraries
> -(i.e.,
> -libc5 or libc6/glibc)
> -based on what C libraries,
> -if any,
> -the library was linked against.
> -.\" The following sentence looks suspect
> -.\" (perhaps historical cruft) -- MTK, Jul 2005
> -.\" Therefore, when making dynamic libraries,
> -.\" it is wise to explicitly link against libc (use \-lc).
> -.PP
> -Some existing libraries do not contain enough information
> -to allow the deduction of their type.
> -Therefore,
> -the
> -.I /etc/ld.so.conf
> -file format allows the specification of an expected type.
> -This is used
> -.I only
> -for those ELF libraries which we can not work out.
> -The format
> -is "dirname=TYPE",
> -where TYPE can be libc4,
> -libc5,
> -or libc6.
> -(This syntax also works on the command line.)
> -Spaces are
> -.I not
> -allowed.
> -Also see the
> -.B \-p
> -option.
> +.\" Support for libc4 and libc5 dropped in
> +.\" 8ee878592c4a642937152c8308b8faef86bcfc40 (2022-07-14) as "obsolete
> +.\" for over twenty years".

I prefer removing the code completely.  Since removing code is more delicate, 
and to help whoever may want to investigate history in the future, please do so 
in a separate commit.  I guess it will be better if that commit removing code 
goes before the general revision of the page.

Cheers,

Alex

> +.\".PP
> +.\".B \%ldconfig
> +.\"will attempt to deduce the type of ELF libraries
> +.\"(i.e.,
> +.\"libc5 or libc6/glibc)
> +.\"based on what C libraries,
> +.\"if any,
> +.\"the library was linked against.
> +.\".\" The following sentence looks suspect
> +.\".\" (perhaps historical cruft) -- MTK, Jul 2005
> +.\".\" Therefore, when making dynamic libraries,
> +.\".\" it is wise to explicitly link against libc (use \-lc).
> +.\".PP
> +.\"Some existing libraries do not contain enough information
> +.\"to allow the deduction of their type.
> +.\"Therefore,
> +.\"the
> +.\".I /etc/ld.so.conf
> +.\"file format allows the specification of an expected type.
> +.\"This is used
> +.\".I only
> +.\"for those ELF libraries which we can not work out.
> +.\"The format
> +.\"is "dirname=TYPE",
> +.\"where TYPE can be libc4,
> +.\"libc5,
> +.\"or libc6.
> +.\"(This syntax also works on the command line.)
> +.\"Spaces are
> +.\".I not
> +.\"allowed.
> +.\"Also see the
> +.\".B \-p
> +.\"option.

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-01-06  1:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05 22:52 [PATCH v3 05/13] ldconfig.8: Revise and update for glibc 2.32 G. Branden Robinson
2023-01-06  1:21 ` Alejandro Colomar [this message]
2023-01-06  7:20   ` G. Branden Robinson
2023-01-06 12:44     ` Alejandro Colomar

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=2ef7c0b8-978e-7bc0-d5b9-88ea9348a677@gmail.com \
    --to=alx.manpages@gmail.com \
    --cc=g.branden.robinson@gmail.com \
    --cc=linux-man@vger.kernel.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