Re: [ptxdist] [PATCH] monit: Add dependency to nsl

[Alexander Dahl <ada@thorsis.com>]

Hello Michael,

Am Fri, Nov 18, 2022 at 12:32:25PM +0100 schrieb Michael Olbrich:
> On Mon, Oct 24, 2022 at 03:01:10PM +0200, Alexander Dahl wrote:
> > Am Montag, 24. Oktober 2022, 14:28:50 CEST schrieb Alexander Dahl:
> > > Am Montag, 24. Oktober 2022, 10:30:35 CEST schrieb Alexander Dahl:
> > > > Console log is flooded with this:
> > > >     /usr/bin/monit: error while loading shared libraries: libnsl.so.1:
> > > > cannot open shared object file: No such file or directory
> > > > 
> > > > Output of readelf is this:
> > > >     Dynamic section at offset 0xa5a50 contains 35 entries:
> > > >       Tag        Type                         Name/Value
> > > >      
> > > >      0x00000001 (NEEDED)                     Shared library: [librt.so.1]
> > > >      0x00000001 (NEEDED)                     Shared library: [libm.so.6]
> > > > 
> > > >      0x00000001 (NEEDED)                     Shared library:
> > > > [libpthread.so.0] 0x00000001 (NEEDED)                     Shared library:
> > > > [libcrypt.so.1] 0x00000001 (NEEDED)                     Shared library:
> > > > [libresolv.so.2] 0x00000001 (NEEDED)                     Shared library:
> > > > [libnsl.so.1] 0x00000001 (NEEDED)                     Shared library:
> > > > [libc.so.6] 0x00000001 (NEEDED)                     Shared library:
> > > > [ld-linux-armhf.so.3]
> > > > 
> > > > Console log flooding is gone after setting the option.
> > > > 
> > > > Signed-off-by: Alexander Dahl <ada@thorsis.com>
> > > > ---
> > > > 
> > > >  rules/monit.in | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/rules/monit.in b/rules/monit.in
> > > > index 383433e78..9db337331 100644
> > > > --- a/rules/monit.in
> > > > +++ b/rules/monit.in
> > > > @@ -3,6 +3,7 @@
> > > > 
> > > >  menuconfig MONIT
> > > >  
> > > >  	tristate
> > > >  	prompt "monit                         "
> > > > 
> > > > +	select LIBC_NSL
> > > > 
> > > >  	select OPENSSL if MONIT_SSL
> > > >  	select ZLIB if MONIT_ZLIB
> > > >  	select BUSYBOX_START_STOP_DAEMON if MONIT_STARTSCRIPT
> > > 
> > > Well, this works with OSELAS.Toolchain-2018.02.0/arm-v7a-linux-gnueabihf
> > > which I used up to now in the BSP in question.  However on another BSP with
> > > OSELAS.Toolchain-2020.08.0/arm-v7a-linux-gnueabihf I get the following
> > > error:
> > > 
> > >   [74/86] started : glibc.targetinstall
> > >   install_copy_toolchain_lib: libnsl.so not found
> > > 
> > > Both BSPs are still on ptxdist-2021.03.0 … what's the best way to quickly
> > > solve this?  Upgrade to recent ptxdist and toolchain might be possible, but
> > > that takes quite some time, and I don't have much for that currently, so an
> > > alternative approach would be appreciated. O:-)
> > 
> > Backported commit fd688d2239bc ("glibc: specify the major version number when 
> > installing most of the libraries") now and builds are successful again with 
> > both toolchains.  Runtime testing will follow, but I'm confident.
> 
> So, libnsl is not actually needed. It's just a broken configure script. If
> you enable PTXCONF_TARGET_LINKER_AS_NEEDED then it will be gone. 

Meanwhile I identified two more packages showing similar problems:
fcgi and log4cplus.  Both check for nsl in their prepare stages, fcgi
with autotools, and log4cplus with CMake.  However I could not tell
from their source or version control, why they do it.  Might be
related to usage of gethostbyname() but I'm not sure if that really
requires libnsl?

If built without PTXCONF_TARGET_LINKER_AS_NEEDED both show -lnsl in
compile stage and dependency to libnsl when inspecting with
`readelf -d`.  Those dependencies are gone when built with
PTXCONF_TARGET_LINKER_AS_NEEDED.  I read [1] and [2] to understand
that linker option and on quick glance it seems like a good idea.  Not
sure if it's safe to enable however or if that could cause unexpected
problems. (I will try, currently runtime testing builds with that
option set.)

> Or add ac_cv_lib_nsl_inet_addr=no to the _CONF_ENV. A patch with
> that should show up im master in the near future.

I backported this to monit in my BSP, and it worked.  Should we do
something similar with fcgi and log4cplus, or is it sufficient to
either enable PTXCONF_GLIBC_NSL or PTXCONF_TARGET_LINKER_AS_NEEDED?

Greets
Alex

[1] https://wiki.gentoo.org/wiki/Project:Quality_Assurance/As-needed
[2] https://www.man7.org/linux/man-pages/man1/ld.1.html