While I agree with Bob, we should all build everything with all symbols resolved, I also do not believe ltdl should force this on everything in a project. So I'm inclined to give thumbs up to a patch that fixes that.
Robert Boehne On Apr 8, 2014 9:53 AM, "Akim Demaille" <a...@lrde.epita.fr> wrote: > Hi Bob! > > Le 8 avr. 2014 à 16:28, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> a > écrit : > > > On Tue, 8 Apr 2014, Akim Demaille wrote: > > > > This option is necessary in order to build DLLs under Windows (and > likely shared libraries under AIX). > > I do understand it is needed on some platforms, but I > don't aim at these. > > > It expects a commitment to supply all dependency libraries at > library/module link time. > > Which almost means additional dependencies and time spent > in relinking. Which I try to avoid as much as possible. > > > You could edit the copy of libltd/Makefile.inc in your project if it > causes an issue for you but there may be consequences for platforms which > need it. > > Yes, I know. But still, to me it looks like something which > is probably not meant to be. After all, it decides for the > whole package what options should be passed for all libraries. > > It should rather be scoped to libltdl only, and the documentation > should emphasize the relevance of -no-undefined (which it already > does). > > > GraphicsMagick uses a non-recursive build and used to build libltdl as > part of the build (for at least 8 years). Even though ltdl added > -no-undefined it was not a problem since GraphicsMagick was intentionally > using this option. > > > > Since then, I realized that building libltdl as part of the project was > prohibitive, costly, and dangerous. It was better to rely on libltdl to be > a formally installed dependency on the system. Now GraphicsMagick treats > libltdl just like any other external library and life is much improved. I > would encourage any other package to not bundle libltdl and to simply > document that it must already be installed on the system. > > What do you mean by dangerous? In case of mixture of versions I guess? > This is probably a problem for libraries that likely to be linked in > a program that links with even more libraries. > > And for "prohibitive and costly", I'd be happy too to have some details :) > It's not too big, and very fast to build (compared to the remainder > of my severely-templated C++ libraries, it is perfectly negligible). > _______________________________________________ > https://lists.gnu.org/mailman/listinfo/libtool >
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
