John Femiani wrote:
Is this issue specific to mingw, or does it apply to cygwin's gcc as well (or Interix, or whatever, if they are supported by boost?)
It is specific to mingw. cygwin uses the unix convention of .a and .so files.
Really? I'll have to try that -- the redhat website seems to say that -lxyz would never find a '.so' file. http://tinyurl.com/6bygtj
Would it be acceptable if there were a different target or option to generate .lib files with toolset=gcc, in addition to generating .dll.a?
You mean something similar to --layout=system ? What would you suggest?
The whole point is that boost currently has naming that is aimed at the platform and not primarily on the used toolset. I am not sure this really should be changed, but ...
Since when? It used to be that mingw produced .a files, and that makes perfect sense to me. Do you try to produce object files with '.obj' or '.o' extensions? As I see it, .exe and .dll files don't need to be fed back into the toolchain again. A .lib or .a file is different, it is only partialy built. It needs to be fead _back_ into the toolchain in order to produce a .dll or .exe at some point. I buy the "platform" argument for .dll and .exe, but I think that the intermediate files like static libs and objects should use the toolchains convention, or at LEAST extensions that work with the toolchain in a way that does not require detective work. That, by the way, seems to be the convention used by mingw itself. They use .dll and .exe, but stick with .o and .a for objects and static libs.
Since xyz.lib has less priority than libxyz.a, adding a .lib won't cause g++ to pick the wrong library with -lxyz. One would still need a g++ .dll.a version or else g++ would try to choose the static library even when one wanted dyamic linking.
If I understand you well you mean both libs should be generated?
It could go either way, but I think the default should be to produce dll.a only. An option to produce .lib in addition or instead could satisfy people who want to compile with gcc but link their final app with msvc. Really, you need .lib files (as opposed to .a) if you are mixing compilers, or rather mixing toolchains. That is useful but should not be the default behavior, it should require another explicit option.
Hmm, smells like bloat, doesn't it?
I am suggesting "bloat" that the user must specifically ask for (so I wouldn't call it bloat). I suppose hard links could be used on newer windows if you want to save on disk space? -- John