11

I built Boost for VS2013, 64-bit architecture using both b2.exe and bjam.exe. According to Boost documentation, b2 must be used over bjam. The differences I notice are:

  1. The size of .lib files from b2 differs from that of the respective bjam file.
  2. Using bjam provides dynamic .lib libraries (without -s tag as mentioned here), but it doesn't provide the .dll files to link to (so what to do now?), whereas using b2 gives both static and dynamic libraries along with the .dll files. But the problem using b2 is, it gives two dynamic .lib files - one starts with boost_xxxx.lib and other with libboost_xxxx.lib and both are of different sizes. Why is that?

Also I mentioned different build directory using the build option --build-dir, but what is the use of this directory? It consists of .obj, .rsp along with respective .dll and .lib files. Can this directory be deleted?

Here are the commands I used to build Boost:

  1. b2: 

    b2 toolset=msvc-12.0 --build-type=complete architecture=x86 address-model=32 install --build-dir=<build-dir> stage --stagedir=<stage-dir> -j2

  2. bjam: 

    bjam stage --stagedir=<stage-dir>
Praetorian
  • 106,671
  • 19
  • 240
  • 328
Aniruth
  • 155
  • 1
  • 2
  • 11
  • 3
    On my build of Boost using 64-bit VS2013 [b2.exe and bjam.exe are identical](http://www.boost.org/build/doc/html/bbv2/faq/names.html) if you diff them. I don't see the `-s` tag difference on the page you link to. If `s` is present in the ABI part of the filename, that means you asked Boost to statically link to the runtime. When you build Boost DLLs the `boost_xxxx.lib` are [import libraries](https://stackoverflow.com/q/3573475/241631) for the corresponding Boost DLLs, so you can link to them at link time. `libboost_xxxx.lib` are static Boost libraries. – Praetorian Jul 10 '15 at 23:51
  • @Praetorian thanks. I am sorry, but I understand the difference between a statically and dynamically linked library. My question is how does libboost_xxxx.lib become a static library without the `-s` tag? I have a file named boost_xxxx.lib (without `-s` tag) with it's DLL and a file named libboost_xxxx.lib (again without `-s` tag) without it's DLL and a file named libboost_xxxx-s.lib (with a `-s` tag). So why do I have 2 import libraries but only one has it's DLL file? And if what you're saying is right, why do I have 2 static libraries? [An example](http://postimg.org/image/blzpf08xx/). – Aniruth Jul 11 '15 at 10:48
  • 2
    It's not statically linking to the runtime by accident, you must've asked b2 to do that. Presumably you also asked it build you the runtime linked version (without `s`). You can do that by using `runtime-link=static,shared`. Your questions would be a lot easier to answer if you would update the question with the exact commands you invoked b2/bjam with. – Praetorian Jul 11 '15 at 20:29
  • 1
    Well, this just took a turn for the ridiculous, didn't it? You're invoking b2 and bjam (which we've already established are identical) with different options and are then surprised that that produces different build artefacts? I believe the default `--build-type` is `minimal`, which only builds release versions of the Boost libs, while `--build-type=complete` in your example would build all possible variants. I know the Boost build documentation is not the best, but if you Google for specific options you will find them being discussed on the Boost mailing list or elsewhere. – Praetorian Jul 13 '15 at 16:43
  • 1
    @Praetorian Now that you mention it, I too see my ridiculousness involved. Anyways, thanks for all the replies. I appreciate it. – Aniruth Jul 13 '15 at 21:47

1 Answers1

8

b2 and bjam are identical files except for their names. The different results are a consequence of calling them with different arguments.

About the preferred name: calling ./b2 --help and ./bjam --help both yield the name b2.

yeoman
  • 1,671
  • 12
  • 15
  • Very nice "--help" on both makes indeed the exact same description. So the question now is why the hell they keep both? Maybe compiling Boost isn't enough complex? :D – Patapoom Nov 08 '19 at 10:03
  • It's not exactly the tidiest of projects ^^ – yeoman Nov 08 '19 at 17:05
  • Plus, I guess they could have gone for a symlink or CSH script for the legacy bjam executable, except, of course, that boost supports the "Microsoft Windows" family of platforms where both are not an option, and instead of just using a copy of the binary on the "Microsoft Windows" platform and one of the other solutions elsewhere, they went for simplicity and consistency from a technological point of view, which I fully understand and actually endorse in this very specific case – yeoman Dec 21 '19 at 17:47