bug#78321: libtool fails to run ldconfig correctly on GNU/Linux

--000000000000ab0f4d0634a1d4d7
Content-Type: text/plain; charset="UTF-8"

I'm following up on
https://lists.gnu.org/archive/html/libtool/2014-05/msg00024.html

I just ran into the same problem: a user reported they had to run
`ldconfig` manually after running `[sudo] make install` on one of my
projects (Free Recode, formerly GNU Recode). I was surprised, as I thought
the autotools ran ldconfig automatically. They do! But on GNU/Linux systems
they run `ldconfig -n`, which does not update the cache, as it implies the
-N option. This means that libraries are not found after installation.

I checked git, and this usage goes back to the initial commit. I wonder
whether something changed since then. Mostly obviously, the -n flag causes
ldconfig to process only the directories specified on the command line,
which I guess is desirable. I can't see a way to update the cache while
retaining this behaviour of -n, but maybe that doesn't make sense?

Anyway, it seems that either we should simply remove the -n flag from the
ldconfig invocation (as on BSD), or document that users will most likely
need to run ldconfig themselves after installation (which seems a shame).

-- 
https://rrt.sc3d.org

--000000000000ab0f4d0634a1d4d7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small" class=3D"gmail_default">I&#39;m following up on <a href=3D=
"https://lists.gnu.org/archive/html/libtool/2014-05/msg00024.html">https://=
lists.gnu.org/archive/html/libtool/2014-05/msg00024.html</a></div><div styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small" class=3D"gmail=
_default"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small" class=3D"gmail_default">I just ran into the same problem: a =
user reported they had to run `ldconfig` manually after running `[sudo] mak=
e install` on one of my projects (Free Recode, formerly GNU Recode). I was =
surprised, as I thought the autotools ran ldconfig automatically. They do! =
But on GNU/Linux systems they run `ldconfig -n`, which does not update the =
cache, as it implies the -N option. This means that libraries are not found=
 after installation.</div><div style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small" class=3D"gmail_default"><br></div><div style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small" class=3D"gmail_default">I=
 checked git, and this usage goes back to the initial commit. I wonder whet=
her something changed since then. Mostly obviously, the -n flag causes ldco=
nfig to process only the directories specified on the command line, which I=
 guess is desirable. I can&#39;t see a way to update the cache while retain=
ing this behaviour of -n, but maybe that doesn&#39;t make sense?</div><div =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small" class=3D"g=
mail_default"><br></div><div style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small" class=3D"gmail_default">Anyway, it seems that either we =
should simply remove the -n flag from the ldconfig invocation (as on BSD), =
or document that users will most likely need to run ldconfig themselves aft=
er installation (which seems a shame).<br></div></div><br><span class=3D"gm=
ail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signatu=
re" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"lt=
r"><a href=3D"https://rrt.sc3d.org" target=3D"_blank">https://rrt.sc3d.org<=
/a></div></div></div></div></div>

--000000000000ab0f4d0634a1d4d7--