Hi Gary, On Monday 09 July 2007 17:47:13 Gary V. Vaughan wrote: > All the world is not Linux. By not shipping libltdl at all, you're > making life difficult for the users of hundreds of other platforms who will > have to install their own libltdl just to build your package, which many > will likely decide is too much effort.
well, my software works on linux, netbsd, freebsd, openbsd, dragonflybsd, debian/bsd debian/hurd, mac os X, solaris and windows, and i think I got success reports about aix and hpux, and embedded linux systems. I don't remember getting negative reports, so don't think the current situation without a copy of ltdl is bad. also at least two projects are libraries used by other applications, in one situation the library is actually an implemention of an ABI plugin standard. in those cases I may not link with my own copy of ltdl at all, but absolutely must use a shared copy of ltdl that can be used by both me and the application loading my "plugin". (I hope I'm understanding this correctly, but as far as I know having the same symbols in an application / the library it loads and a plugin / the shared libs that depends on) is a recipe for desaster or won't work at all on some plattforms.) so using a private copy of some library statically linked into my plugin could lead into problems (we had that necessity with openssl 0.9.6 and it was not pretty). also including a private copy of some code creates a maintenance nightmare for distribution. maybe you remember the zlib security issues a few years ago? the found dozends of copies in all kind of software that used a copy for convenience of the developers - and thus created extra maintenence work for the distributions. that won't happen very likely to ltdl, but still the lesson learned applies as general rule I think. > This still requires that you have a copy of libltdl in your package sorry, don't want to do that. distributions would need to change their spec files and rules files to add extra configure parameters, I don't want to create extra work for them. its not much work, but some maintain about 20k packages, so every small change counts. > I say "supposed" because that part of the tree is currently in flux > as we work towards an alpha release from HEAD in the coming months. ah, ok. thanks for the heads up. could you consider adding a pkg-config .pc file that is installed with the shared version of libltdl? that way people like me could use the normal macro package we use for every library, and wouldn't need to write special configure code or anything. pkg-config made configure script much more readable (compared to the spaghetti code I saw for years in way too many projects). Thanks for your help! though I'm still looking for a nice generic macro packages for finding ltdl, now that the latest version included in gettext is broken for me. maybe I should move to that mailing list and ask how I can use their macro package without the gettext dependency, as it was quite generic until recently. Regards, Andreas _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool