Fix nsss linkage

[man-gc]

When enabling nsss, execline fails to compile with the following message:

| ./tools/gen-multicall.sh > src/multicall/execline.c
| make: *** No rule to make target '-lnsss', needed by 'execline'.  Stop.
| make: *** Waiting for unfinished jobs....

This is due to the fact that 'tools/gen_deps.sh' expects that each external library variable ends in '_LIB' to add it to the 'EXTRA_LIBS' variable for the executable target. So, rename the dependency and re-run 'tools/gen-deps.sh' to fix this.

[skarnet]

This is incorrect. EXTRA_LIBS is only used for libraries that are outside of our control and cannot be resolved by vpath, such as -lrt or -lpthread. For libraries that are under our control, vpath is used to convert -lnsss to the full path to the library; this is what happens with -lskarnet for instance.

The error message you got likely means that your vpath was not properly configured, i.e. you installed nsss in a non-default location and did not use the corresponding --with-lib or --with-dynlib option when configuring execline.

[man-gc]

@skarnet Thank you for your response. To provide a little more context, I was trying to build under Yocto which installs a specific sysroot for each built package. I am not really sure if that has an impact on vpath and, in that case, how it should be configured.

You are citing -lskarnet as an example, but in the very same file, it is added to EXTRA_LIBS, so it seemed sensible to me to do the same for -lnsss

I have tried the solution you mentioned with --with-lib or --with-dynlib but I couldn't make it link properly. Only adding nsss to EXTRA_LIBS seems to solve my problem.

[skarnet]

Right, there is an inconsistency there... the version of gen-deps.sh used by execline treats -lfoobar the same way as it treats ${FOOBAR_LIB}, but -lskarnet ideally should be handled by vpath since it is under our control. I'll fix that in the future; getting the build system to do exactly what I want is hard.

My point is that build dependencies to the skarnet.org stack, if packages are installed in a non-default place, should be handled by --with-include, --with-lib and --with-dynlib options. These options take the paths to header files, static libraries and dynamic libraries as seen by the build system, not the runtime system, so if Yocto installs stuff under $staging/usr, for instance, and you're using FHS, you'd call ./configure --with-include=$staging/usr/include --with-lib=$staging/usr/lib --with-dynlib=$staging/lib or something like that.

Yes, this is annoying to type and different from autoconf-generated configure scripts, but it is the intended way since it allows you to control whether to link against the static or dynamic version of the skarnet.org stack even if you're linking your libc dynamically; whereas EXTRA_LIBS doesn't give you that flexibility, it just passes -lfoobar to the linker and lets it decide, which is hazardous when you're interested in semi-static builds.

[man-gc]

getting the build system to do exactly what I want is hard.

Build systems are hard... that's why we keep reinventing new ones... But I remember reading something about VPATH builds in the autotools documentation. And adding, cross compilation to the mix doesn't make it easier. In my case, Yocto makes it easy to decide what is available to the build. Each package gets its own staging directory containing only the dependencies it requires (copied from the install phase of the dependency build). I think that makes it different from other build systems AFAIK.

you'd call ./configure --with-include=$staging/usr/include --with-lib=$staging/usr/lib --with-dynlib=$staging/lib or something like that.

That's what I've tried and by inspecting the output of readelf, I saw that execline did not link against libnsss. But maybe I should test with a clean sysroot to make sure there was no leftover from previous tries.

Yes, this is annoying to type and different from autoconf-generated configure scripts

FYI, I already had to add --with-sysdeps to accomodate the $staging directory so adding some directives won't be a problem as long as I can make it work.

[man-gc]

OK, I have finally made it work with your advices. Thanks for your help, I'm closing this pull request since it breaks the intended behavior.