LWN.net Logo

The article is correct

The article is correct

Posted Apr 1, 2012 10:14 UTC (Sun) by khim (subscriber, #9252)
In reply to: The article is correct by danieldk
Parent article: Free is too expensive (Economist)

Another possibility would be to statically link the application, but that has its own problems (e.g. no dlopen()).

You can link some libraries statically and the rest dynamically. GlibC, in particular, is remarkably stable and it's easy to support older distributions with older versions of GlibC via LSB.

Something like -Wl,-Bstatic -lunstablelib1 -lunstablelib2 -Wl,-Bdynamic should do the trick.

Of course dlopen creates complications: if you want to use some library both from plugin and from main application (or just from two plugins) then you'll end up with two copies of library in memory! This, too, is solvable (for example you can add appropriate library to the main executable and use --export-dynamic to make it available for plugins), but yes, it's a PITA.

Yet you solve this somehow for MacOS and Windows (last time I've checked Windows had no DB XML support) thus it should be solvable for Linux, too.

The biggest problem with Linux is Q&A: if you limit yourself to LSB then you can not do a lot of things which are expected from modern program and if you use libraries outside of LSB then you immediately lose then cross-distribution compatibility and need to test your application with different versions of different distributions.


(Log in to post comments)

The article is correct

Posted Apr 1, 2012 11:50 UTC (Sun) by danieldk (guest, #27876) [Link]

> You can link some libraries statically and the rest dynamically. GlibC, in particular, is remarkably stable and it's easy to support older distributions with older versions of GlibC via LSB.

Good point, thanks!

> Yet you solve this somehow for MacOS

By providing an application bundle, which is a standardized procedure and something users expect. Also, (ABI-stable) system libraries are not copied to the application bundle. So, the bundle only contains a fraction of the used libraries (Qt and DBXML).

> and Windows

Again, here we use standard libraries (VS2008 redistributable), and drop Qt/DBXML DLLs in the same directory as the executable and it works perfectly on Windows XP and up (probably also Windows 2000, but we didn't check), although the software is compiled on Windows 7.

> (last time I've checked Windows had no DB XML support)

There's Windows support for DB XML. Oracle offers pre-built DLLs, or a source archive with Visual Studio project files. We use the latter, and building the DLLs with Visual Studio 2008 is just one click.

http://www.oracle.com/technetwork/products/berkeleydb/dow...

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds