Hi Rune, On Thu, May 02, 2013 at 10:37:58AM +0000, u-tcc-u...@aetey.se wrote: > From my perspective I'd like to skip the additional worry about which > programs can be linked to which libraries and "how".
if you are a packager, why do you have to worry about that? I mean, if you still have the possibility to chose which library to link to, most of the time the program is already (L)GPL compatible. And if you always use the shared library, there is never a problem with LGPL. > I dislike dynamic linking for technical reasons (too much complexity, > artificial limitations and side effects, many times for no gain). Then, > I dislike licenses which force me to use inferior/inappropriate technical > means. Can you elaborate on that? Aside from some people not understanding how to use SONAMEs (Tegra 2 libjpeg.so binary blob...), I've never had problems with shared libraries. Off the top of my head I remember three cases where shared libs were superior: - Libgcc for ARM once had a bug in the division routine. If all applications had linked to the shared library, it would have been enough to replace just a single file. - Libpng has multiple times been updated because a vulnerability had been found in the code. And guess what, Firefox per default links statically to its own copy of libpng, so you have to replace Firefox as well. - I once had to squeeze ISC DHCP into a little NOR flash but each of the applications was linked statically to several ISC libraries and it appeared like no code was discarded during linking. It all magically fit once I persuaded the build process to create and use shared libraries. > BSD license makes the software easier to package / deliver, which > can make a big difference in certain cases. Btw., how do you at Aetey manage to provide the source code for the (L)GPL software you host? Best regards, Daniel _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel