On 7/23/20 5:00 PM, Bruno Haible wrote: > GNU poke is likely to use GMP soon. When it does that, it will of course use > the module 'libgmp'. And this package happens to use libtool. That's fine, all I'm asking for is the ability to use libgmp without using havelib. A package that uses havelib shouldn't be affected. > You can. For uses of system-wide installed GMP, nothing changes. For users who > built GMP on their own, there is the configure option --with-libgmp-prefix. If > there is a problem with it, you can redirect the reports to bug-gnulib or me. That --with-libgmp-prefix worries me, for Emacs in particular. The Emacs folks are already somewhat resistent to Gnulib and want to minimize the attendant configury. I doubt whether they'd like to add instructions for --with-libgmp-prefix, --with-libxyz-prefix, etc. to their documentation. Instead, they use pkg-config for many libraries, and this works reasonably well for them. I'd rather not add yet another way to do libraries. I can envision another problem with the havelib approach. For a program like Emacs that links many libraries, there is a performance overhead to having a long -rpath, so it makes sense to have a single directory (/home/eggert/lib, say) for all my personal libraries. But if I do that, then GNU coreutils 'factor' will have /home/eggert/lib in its rpath whereas 'sort' won't (because 'sort' doesn't use GMP). And then if I improve glibc and place an improved version into /home/eggert/lib, this will affect 'factor' but not 'sort' because 'factor' is linked with $(LIBGMP) but 'sort' is not. This will be confusing. There is an irreducible amount of complexity in dynamic linking. I don't much like the traditional approach of using -Wl,-rpath in LDFLAGS, and I don't much like pkg-config either. It is a pain no matter what we do. To work around the immediate problem (since this is blocking gnulib integration into Emacs) I installed the attached patches into Gnulib. (The first one should be routine.) Perhaps we can think of something better.