On Wed, 19 Dec 2007, Vladimir Prus wrote:
John Maddock wrote:
Rene Rivera wrote:
John Maddock wrote:
If I do a:
bjam stage --toolset=msvc-8.0 --with-regex
Then with 1.35 I don't get any static libraries built, just the dll's. Was this a deliberate change somewhere? It's a problem because the default for auto-linking is to look for static rather than dynamic libraries.
Yes, it was intentional <http://article.gmane.org/gmane.comp.lib.boost.devel/168552>. We also discussed it at one point <http://article.gmane.org/gmane.comp.lib.boost.devel/166847>. I guess we should switch autolink to default to the dynamic libs?
...
If the aim is to reduce the number of variants built, then I would suggest:
Dymanic *and* static lib, as Release, multithreaded, dynamic runtime single build on Unix variants (2 build variants).
I'd be opposed to this. How many popular projects can you name, that build two variants on Linux?
Qt does something clever on Linux. Their installed libs look like lrwxrwxrwx 17 libQtGui.so -> libQtGui.so.4.3.1 lrwxrwxrwx 17 libQtGui.so.4 -> libQtGui.so.4.3.1 lrwxrwxrwx 17 libQtGui.so.4.3 -> libQtGui.so.4.3.1 -rwxr-xr-x 8227640 libQtGui.so.4.3.1 -rw-r--r-- 67812225 libQtGui.so.4.3.1.debug libQtGui.so.4.3.1 contains a special ELF section, .gnu_debuglink, that points the debugger to libQtGui.so.4.3.1.debug. This way they can install a "multithreaded release variant", but it points gdb to a file with all the Dwarf information needed for a "debug variant". Deleting that .debug file won't hurt people who don't use the debugger. I haven't taken the time to figure out how they build this, but it looks like a worthwhile trick. - Daniel