Re: [boost] [Boost-build] [1.35] what gets built and installed?
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?
That's actually not possible without changing folks library code: it's a per-library decision which is the default, with the static library being recomended as the default unless there are reasons to choose otherwise. There's a great deal of documentation that would have to change to reflect this as well. There's also a rationale for why static linking is the default behaviour in our docs here: http://www.boost.org/more/separate_compilation.html#static_or_dynamic There's a further issue with building only one variant under MSVC: it doesn't work! By only building a release build, then the only thing that will work "straight out the box" is building a release build of your application against the dll runtime. Debug builds will generate linker errors (can't find the auto-linked library etc), as will builds against the static runtime, this means that Boost will appear totally broken if users try and build the default debug builds that their IDE gives them. We need to be *very* careful with this, or the complaints will be loud and vociferous! 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). Dynamic *and* static lib, Release *and* Debug, multithreaded, dynamic runtime on Win32 compilers (that's 4 build variants). That's an absolute minimum IMO. Even then we will have to be very careful that our build instructions indicate very clearly how to build the other variants, especially for those msvc users :-) Sorry to be the bearer of the bad news, John. PS this is too important and far reaching to be discussed only on boost-build IMO.
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?
That's actually not possible without changing folks library code: it's a per-library decision which is the default, with the static library being recomended as the default unless there are reasons to choose otherwise. There's a great deal of documentation that would have to change to reflect this as well.
There's also a rationale for why static linking is the default behaviour in our docs here: http://www.boost.org/more/separate_compilation.html#static_or_dynamic
There's a further issue with building only one variant under MSVC: it doesn't work!
By only building a release build, then the only thing that will work "straight out the box" is building a release build of your application against the dll runtime. Debug builds will generate linker errors (can't find the auto-linked library etc), as will builds against the static runtime, this means that Boost will appear totally broken if users try and build the default debug builds that their IDE gives them.
We need to be *very* careful with this, or the complaints will be loud and vociferous! 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? - Volodya
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
dherring@ll.mit.edu wrote:
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.
This, still, is a single variant -- release with debug symbols, where debug symbols are then moved to a separate file. And release variant is not the best thing to debug, due to code flow messed up, variable optimized out, and so on. Generation of .debug file is documented at: http://sourceware.org/gdb/current/onlinedocs/gdb_16.html#SEC154 - Volodya
dherring@ll.mit.edu wrote:
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.
This works as long as both variants contain the same code. However, if the release variant is built with -DNDEBUG and the debug variant is not (say, to activate assert() only in debug mode), you really do need two separate builds. (On the topic of optimizing multi-variant builds: at least on Linux it is possible to use the same object files for DSOs as well as archives, so in principle it wouldn't be necessary to recompile everything twice in order to get shared and static build variants.) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
John Maddock wrote:
Vladimir Prus wrote:
I'd be opposed to this. How many popular projects can you name, that build two variants on Linux?
Every single one that uses libtool:
That's a strong statement, are you really sure? ;-) That's only true if a project does not decide to disable static linking, as documented at: http://www.delorie.com/gnu/docs/libtool/libtool_27.html Say, one popular example of C++ on Linux is KDE 3.* stack -- which has static linking disabled. After fresh build, for me, there are 64 .so files and a total of one .a file. Current version of GtkMM (C++ wrapper of Gtk) likewise disables static builds. And it's not like all C projects build both variants either ;-) - Volodya
Vladimir Prus wrote:
John Maddock wrote:
Vladimir Prus wrote:
I'd be opposed to this. How many popular projects can you name, that build two variants on Linux?
Every single one that uses libtool:
That's a strong statement, are you really sure? ;-) That's only true if a project does not decide to disable static linking, as documented at:
OK, I overstated the case, Consider me duly chastised :-) John.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: 20 December 2007 12:48 To: boost@lists.boost.org Subject: Re: [boost] [Boost-build] [1.35] what gets built and installed?
OK, I overstated the case,
Consider me duly chastised :-)
Sympathy ;-) But John's initial assessment of this problem is correct - this is an 8 on the Richter scale in terms of the impending response from the 'great unwashed' - MS IDE users. They (including me!) 'just want it to work' - and a massive collection of library files is the least worst option. Static linking also avoid the files bloat and separate dll issue and so will remain popular with some. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
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?
That's actually not possible without changing folks library code: it's a per-library decision which is the default, with the static library being recomended as the default unless there are reasons to choose otherwise. There's a great deal of documentation that would have to change to reflect this as well.
There's also a rationale for why static linking is the default behaviour in our docs here: http://www.boost.org/more/separate_compilation.html#static_or_dynamic
There's a further issue with building only one variant under MSVC: it doesn't work!
By only building a release build, then the only thing that will work "straight out the box" is building a release build of your application against the dll runtime. Debug builds will generate linker errors (can't find the auto-linked library etc), as will builds against the static runtime, this means that Boost will appear totally broken if users try and build the default debug builds that their IDE gives them.
We need to be *very* careful with this, or the complaints will be loud and vociferous!
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). Dynamic *and* static lib, Release *and* Debug, multithreaded, dynamic runtime on Win32 compilers (that's 4 build variants).
That's an absolute minimum IMO. Even then we will have to be very careful that our build instructions indicate very clearly how to build the other variants, especially for those msvc users :-)
Sorry to be the bearer of the bad news,
If a user may be permitted to comment, I think John is correct here. It is far better that the boost build take a long time (with a big warning in the build instructions to that effect) but build all of the normally used variants than having it build only Release shared libraries. My guess is that most Boost users are developing for deployment to their users, and many of them will want their apps to be statically linked to Boost libraries, among others, in order to avoid a whole host of issues. I also can't believe that anyone who uses an IDE for development doesn't build Debug versions much more often, and usually by default, than they build Release versions. This is certainly true for MSVC and Xcode users. I think you will get many complaints and spend a lot of time answering the "how do I build static libraries on platform x" and "how do I build debug libraries" posts if you change the default. If you do change the default behavior to build only Release shared libraries, then you need to make it dead simple to build all of the variants. Best regards, Rush
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?
That's actually not possible without changing folks library code: it's a per-library decision which is the default, with the static library being recomended as the default unless there are reasons to choose otherwise.
OK.
There's a great deal of documentation that would have to change to reflect this as well.
Perhaps... Do you know which docs they might be?
There's also a rationale for why static linking is the default behaviour in our docs here: http://www.boost.org/more/separate_compilation.html#static_or_dynamic
Hm, that doesn't sound to me as a rationale, it's more like an excuse. And I suspect the anecdotal evidence about regex is outdated. Currently we usually recommend, in emails, irc, etc., to use dynamic libraries because of memory management problems with static libs. I remember we mention this in some docs, but I don't remember the specific docs at the moment.
There's a further issue with building only one variant under MSVC: it doesn't work!
Interesting definition of "doesn't work". ;-)
By only building a release build, then the only thing that will work "straight out the box" is building a release build of your application against the dll runtime. Debug builds will generate linker errors (can't find the auto-linked library etc), as will builds against the static runtime, this means that Boost will appear totally broken if users try and build the default debug builds that their IDE gives them.
We need to be *very* careful with this, or the complaints will be loud and vociferous!
OK, currently the most common questions and gripes I get are: * There's are a bunch of stuff built. Which one do I pick? * Why does it take so long to build? * Why can't I just add a single "-lboost_thread"? And the majority of questions I get are not from developers that are using Boost. But from developers who are using Boost as a third party library. And hence the user is only interested in satisfying the dependency. Developers directly using Boost don't tend to ask the above questions. And just figure out which variants to use on their own. Hence I suspect they will easily figure out how to use the "--build-type=complete" option easily.
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).
So, all the problems you mention above are autolink issues. What problems building more than the dynamic libs on Unix address?
Dynamic *and* static lib, Release *and* Debug, multithreaded, dynamic runtime on Win32 compilers (that's 4 build variants).
A tangent... I can't change the default to vary depending on the compiler used. I can only change it depending on the platform one *runs* on. Which may be inappropriate in a cross-compile context. Could you provide some rationale for why those specific variants? Maybe I'm just confused as to why release and debug, and not just debug if you are trying to satisfy the "default" IDE. (note, I'm not an "IDE" person, at least as IDE's are currently defined by the industry)
That's an absolute minimum IMO. Even then we will have to be very careful that our build instructions indicate very clearly how to build the other variants, especially for those msvc users :-)
The goal is not to build a minimum, but to build *1* and leave building more up to the user. I personally think we've reached the point where the Boost libraries are used generically enough that the variant we build should be the one most likely to be used in the field. So perhaps I'm wrong in thinking that the release/mt/dynamic is the one.
Sorry to be the bearer of the bad news,
I rate this about a 0.5/10 in the scale of bad news I've dealt with in the past few weeks ;-)
PS this is too important and far reaching to be discussed only on boost-build IMO.
I didn't intend for that... I just hit reply instead of reply-all. I guess I didn't see why you included the build list at all in the first place :-\ -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
There's a great deal of documentation that would have to change to reflect this as well.
Perhaps... Do you know which docs they might be?
Nope, but I can guess (and would hope) that all the libraries with separate source will mention this somewhere.
There's also a rationale for why static linking is the default behaviour in our docs here: http://www.boost.org/more/separate_compilation.html#static_or_dynamic
Hm, that doesn't sound to me as a rationale, it's more like an excuse.
Ouch.
And I suspect the anecdotal evidence about regex is outdated. Currently we usually recommend, in emails, irc, etc., to use dynamic libraries because of memory management problems with static libs. I remember we mention this in some docs, but I don't remember the specific docs at the moment.
It's probably more accurate to say that it's an MSVC'ism: folks using msvc really don't like distributing dll's with their applications. The complaints to the main Boost mailing list to "please make static linking the default" were really quite persistent until I changed.
There's a further issue with building only one variant under MSVC: it doesn't work!
Interesting definition of "doesn't work". ;-)
Well you can't mix lib's built against the release runtime, with those built against the debug runtime, so debug builds are all but impossible if you only ship a release build. Personnally I'd say that was broken ;-)
We need to be *very* careful with this, or the complaints will be loud and vociferous!
OK, currently the most common questions and gripes I get are:
* There's are a bunch of stuff built. Which one do I pick? * Why does it take so long to build? * Why can't I just add a single "-lboost_thread"?
And the majority of questions I get are not from developers that are using Boost. But from developers who are using Boost as a third party library. And hence the user is only interested in satisfying the dependency.
Understood, and on Linux that may well make sense.
Dymanic *and* static lib, as Release, multithreaded, dynamic runtime single build on Unix variants (2 build variants).
So, all the problems you mention above are autolink issues. What problems building more than the dynamic libs on Unix address?
Mainly it gives the user a choice as to static or dynamic linking: same as you get if you build with libtool for example.
Dynamic *and* static lib, Release *and* Debug, multithreaded, dynamic runtime on Win32 compilers (that's 4 build variants).
A tangent... I can't change the default to vary depending on the compiler used. I can only change it depending on the platform one *runs* on. Which may be inappropriate in a cross-compile context.
Could you provide some rationale for why those specific variants? Maybe I'm just confused as to why release and debug, and not just debug if you are trying to satisfy the "default" IDE. (note, I'm not an "IDE" person, at least as IDE's are currently defined by the industry)
I'm mainly focussing on msvc here, since that's all that supports auto-linking anyway (if we ignore msvc-lookalikes for now). The problem is that msvc ships with multiple C/C++ runtimes: 6 of them for VC71, 4 for VC8, and wait for it... either 8 or 16 depending how you count them for Borland. Libraries built against one runtime *can not be used with any other*, if you try to do so the program may well link OK, but will almost certainly crash at runtime. This is why regex started supporting auto-linking even before Boost: without it even experienced programmers often pick the wrong build variant and then you get a persistent stream of complaints along the lines of "why does your stupid library crash", which are very time consuming to track down and solve. IMO it would actually be better to provide no build system at all for msvc users and say "use your IDE", than to only build one variant. One variant gives the impression that it'll work everywhere when it most certainly will not. BTW, while it is technically possible to use the one of the release runtimes in a debug build with msvc, almost no one does that - the IDE makes it rather tricky to do, and in my experience it often causes hard to track down issues - not least because it confounds the expectations of any other non-Boost libraries that autolink.
That's an absolute minimum IMO. Even then we will have to be very careful that our build instructions indicate very clearly how to build the other variants, especially for those msvc users :-)
The goal is not to build a minimum, but to build *1* and leave building more up to the user. I personally think we've reached the point where the Boost libraries are used generically enough that the variant we build should be the one most likely to be used in the field. So perhaps I'm wrong in thinking that the release/mt/dynamic is the one.
IMO the minimum for msvc is the 4 variants that match the 4 runtimes shipped with vc8. I can't comment on Borland: I seem to remember that the static runtimes shipped by Borland are more stable than the dll's (or have fewer issues anyway), but perhaps a Borland user can comment? Cheers, John.
John Maddock wrote:
Rene Rivera wrote:
A tangent... I can't change the default to vary depending on the compiler used. I can only change it depending on the platform one *runs* on. Which may be inappropriate in a cross-compile context.
Could you provide some rationale for why those specific variants? Maybe I'm just confused as to why release and debug, and not just debug if you are trying to satisfy the "default" IDE. (note, I'm not an "IDE" person, at least as IDE's are currently defined by the industry)
snipped... BTW, while it is technically possible to use the one of the release runtimes in a debug build with msvc, almost no one does that - the IDE makes it rather tricky to do, and in my experience it often causes hard to track down issues - not least because it confounds the expectations of any other non-Boost libraries that autolink.
Even the above which you cite is prone to problems. Recently I was using the release build of ImageMagick DLLs for VC, which I built from source, against a debug version of a program I created using the same version of VC, and ImageMagick crashed when I had to pass to ImageMagick some dynamically allocated data. When I looked at Dependency Walker naturally I saw two versions of the VC RTLs and I suspect the crash had to do with the fact that the release and debug versions of the RTL do not understand each other's dynamically allocated memory ( the debug version may be sticking in data which allows closer checking of valid dynamically allocated areas ). Once I synched up my versions so that the debug version of my application was using the debug version of the same ImageMagick DLLs, there were no problems. So to back you up further, and whether it is the case with most other compilers I do not necessarily know, but using VC libraries has to be absolutely in synch with each other or else problems will occur and the end-user is asking for trouble. I actually believe that the default build for Boost Build for the end-user, upon downloading Boost and following the basic Boost Build instructions, should be to automatically build all variants of a library for a particular compiler, and only if the end-user wants to limit the variants to build should he have clear documentation which tells him how to build some subset or single variant of a particular Boost library for a particular compiler. Needless to say the instructions for the latter should be clear and easy to understand and find. If the end-user does not want all variants, then he should read the documentation and find out how to limit himself. It is MUCH safer to build all variants by default, even if the build takes significantly longer, than to hear endless questions from end-users to Boost programmers, who have much better things to do than fielding them, about why their library is not linking with the end-user's module, only to find that the end-user never built the correct library for his use because the default was to build a different variant.
I am a Windows developer who aleady used boost, and UI think I might share my experience. From my point of view, I do not understand the discussion about the default build type. For serious windows developers, there is no default. John Maddock wrote:
It's probably more accurate to say that it's an MSVC'ism: folks using msvc really don't like distributing dll's with their applications. The complaints to the main Boost mailing list to "please make static linking the default" were really quite persistent until I changed.
From my point of view, I do not understand the discussion about the default build type. For serious windows developers, there is no default. Whenever you create a new project in visual studio, you are asked the questino about using static or dynamic linked runtime. Whatever you select, you need to think about it, and both have serious consequences to your application and the way you distribute it: Static linking means you can just distribute one executable, and you are done. This is nice for small projects, and for tools and utilites you distribute. But it usually makes your application much bigger than it needs to be. But: As soon as your application is split into more than one module (multible EXE files or DLL), you want and need the code reuse. And then you are forced (not really, but you'd better do it) to switch to dynamic runtime. Otherwise you need to be very careful with object/memorys ownership, usage of C++ objects and so on. So whenever I get a third party library to use in my apps, I do not ask how it is built. I just expect at least the mentioned four variants: Debug/Relase vs Dynamic/static linkage. When I rebuild without special options (like --static or --debug) I expect all four variants to be built. And if that is too much, I would expect that I have to chose explicitly which one to build. There is another variant that needs to be considered: statically link to a boost library which then links dynamically to the C/C++ runtime. That way you could hide boost within your application/dll, while still be able to use your compiler*s DLL runtime which might already be on the custome's pc anyway. BTW, all these variants, if built, should be automatically selected with auto-link, of course.
BTW, while it is technically possible to use the one of the release runtimes in a debug build with msvc, almost no one does that - the IDE makes it rather tricky to do, and in my experience it often causes hard to track down issues - not least because it confounds the expectations of any other non-Boost libraries that autolink.
Under windows, the difference between debug and release builds is essential and important. You simply can not run a debug application with a release boost library linking to a debug CRT. The program would most likely fail with very strange errors. Think for instance of iterator debuggin support in the MS std::C++ runtime.
IMO the minimum for msvc is the 4 variants that match the 4 runtimes shipped with vc8.
Well, or 6 variants, as I said above. In our applicatinos, boost is still considered more of a utility part of the application than a runtime library, so it should be possible to do a stati link to boost while linking the dll runtime. At least bost build system should be able to build these libs if required. Norbert
On Dec 20, 2007 12:52 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
Hm, that doesn't sound to me as a rationale, it's more like an excuse. And I suspect the anecdotal evidence about regex is outdated. Currently we usually recommend, in emails, irc, etc., to use dynamic libraries because of memory management problems with static libs. I remember we mention this in some docs, but I don't remember the specific docs at the moment.
What issues are that (with static Boost, dynamic runtime)?
participants (10)
-
dherring＠ll.mit.edu -
Edward Diener -
John Maddock -
Norbert Unterberg -
Olaf van der Spek -
Paul A Bristow -
Rene Rivera -
Rush Manbert -
Stefan Seefeld -
Vladimir Prus