On 12/09/12 08:02, David Tardon wrote: > Hi, > > On Tue, Sep 11, 2012 at 09:24:30AM +0200, Stephan Bergmann wrote: >> On 09/10/2012 06:55 PM, Matúš Kukan wrote: >>> I am pondering gbuildizing neon. >>> It's built by dmake as dynamic library currently. >>> Could it be used as static library ? >> [...] >>> It's used only in ucb/Library_ucpdav1.mk >> >> One gotcha with this logic of preferring a static over a dynamic >> library when only used as a dependency of one other object is that >> this requires us to keep track whether a library is used only once >> or multiple times, to revisit the static vs. dynamic decision. > > I guess we could issue a warning when a static library is used multiple > times. Of course, there are static libraries that are created explicitly > for that purpose, so we would either need a way to avoid these (a > whitelist of libs that are allowed to be linked with multiple times) or > limit this to static libraries from external projects (e.g., doing a > "registration" in gb_StaticLibrary_use_unpacked).
there are also other reasons for linking statically, such as the horrible design flaw of ELF shared libraries where all exported symbols are placed into a single namespace by default; to work around that it is sometimes a good idea to build something as a static library with hidden visibility. also, there are bizarre cases like expat where last time i checked we linked a UTF-16 variant and a UTF-8 variant into different LO libs (if only somebody would rid us of those awful UTF-16 strings...). i don't really think putting a check for this into the build system is merited; but perhaps somebody proves me wrong by reviewing the list of currently multiply linked static libraries and finding large waste of space there :) _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
