On Thu, Jun 19, 2025 at 08:14:26PM +0200, Bruno Haible wrote: > Nick Bowler wrote: > > Won't the problem of setting up shared library search paths be solved > > if you just link the test program using libtool, so the usual wrapper > > programs are generated to setup the platform-specific search paths? > > Most packages that *use* a library do so without using libtool. > For example, coreutils uses several libraries (libintl, libiconv, libgmp, > selinux, openssl, systemd) but does not use libtool. It simply passes > -L and -l (and -Wl,-rpath,...) options directly to the compiler.
If you want to test this specific use case, you can still easily use libtool to link the test program. installcheck_LDFLAGS = -R$(DESTDIR)$(libdir) installcheck_LDADD = -Wc,-L$(DESTDIR)$(libdir),-lfoo On Windows, libtool will generate a wrapper executable which finds the dll installed in $(DESTDIR)$(bindir) when you do this. > Therefore, using libtool for 'installcheck' is the wrong approach, > because it's not what packages do when they use the library. I really don't see how directly invoking the C compiler and trying to re-implement features which libtool already has is going to be productive. > In particular, problems with library dependencies are likely to go > unnoticed if you link with libtool — because libtool uses .la files > which contain information about library dependencies, and normal > users of the library will not use this information. Is there actually a scenario where the .la file which libtool produced has correct dependency information but the shared library which libtool produced has erroneous dependency information? Not saying this never happens but wouldn't that normally indicate a bug in libtool? If there are inter-library dependencies, then a simple -lfoo (unless you use the libtool library...) won't work at all on systems which don't support such dependencies (which is all of them, if you configure with --disable-shared). Cheers, Nick
