Problem in cmake files generated when building with emscripten

[fxcoudert]

I am building boost, and in particular boost-python, for emscripten. My detailed setup is given below. When I run b2, it is clear that the address-model is correctly detected:

Performing configuration checks

    - default address-model    : 32-bit (cached) [1]
    - default architecture     : none (cached) [1]

[1] clang-emscripten

However, in the installed cmake config files, I see this:

# Generated by Boost 1.90.0


if(CMAKE_SIZEOF_VOID_P EQUAL 4)
  _BOOST_SKIPPED("libboost_python313.a" "64 bit, need 32")
  return()
endif()

which is weird because the generated libraries are indeed 32-bit, not 64-bit. I checked:

$ emar x ../boost-install/lib/libboost_python313.a exec.o
$ file exec.o 
exec.o: WebAssembly (wasm) binary module version 0x1 (MVP)

I'm not sure how to debug how these cmake files are created, but something is going wrong. This is preventing further use of cmake with these libraries, since they are wrongly rejected:

  No suitable build variant has been found.
  The following variants have been tried and rejected:
  * libboost_python313.a (64 bit, need 32)

Details

The compilation line is:

./b2 variant=release toolset=clang-emscripten link=static threading=single --layout=system --prefix=/Users/fx/Desktop/pyodide/boost-install -d2 install

The jam file is standard, but I have added:

using clang : emscripten : emcc : <archiver>emar <ranlib>emranlib <linker>emlink ;
using python : 3.13 : python3.13 : /Users/fx/Library/Caches/.pyodide-xbuildenv-0.33.0/0.29.3/xbuildenv/pyodide-root/cpython/installs/python-3.13.2/include/python3.13 : ;

[fxcoudert]

The cmake variant config file is printed by this code path:

boost_install/boost-install.jam

Line 175 in 4be1e57

if $(address-model) = 32

I'm not sure how it's getting that address-model variable, but it seems to be wrong. But something weirder is happening, because the code is:

    print.text

        "# Generated by Boost $(version)"
        ""
        : true ;

    print.text "# address-model=$(address-model)" "" : true ;

    if $(address-model) = 32
    {
[...]

however, the files that are output are like this:

# Generated by Boost 1.90.0


if(CMAKE_SIZEOF_VOID_P EQUAL 4)
  _BOOST_SKIPPED("libboost_python313.a" "64 bit, need 32")
  return()
endif()

# python=3.13

I can see the boost version, I can see the CMAKE_SIZEOF_VOID_P conditional, but the line that should output # address-model=$(address-model) is not actually in the file. How weird is that? Help would be appreciated to figure it out.

[pdimov]

The address-model variable is probably not set at all, which is why the line appears to be skipped (it actually prints an empty line).

Try adding address-model=32 explicitly to your command line. It looks like the default isn't being applied for some reason.

[fxcoudert]

Try adding address-model=32 explicitly to your command line. It looks like the default isn't being applied for some reason.

Yeah that works! Any idea how I can debug why it was not being applied, and how it can be fixed in the build system itself?

[pdimov]

I don't, although @grisumbras might have ideas.

[grisumbras]

Can you create a gist or something similar with the full log?

[fxcoudert]

Here is the full output: https://gist.github.com/fxcoudert/994803e18234a061dd4427ccb5a90b47

[grisumbras]

 - default address-model    : 32-bit (cached) [1]
 - default architecture     : none (cached) [1]

Since arthitecture wasn't deduced, we don't set default address model either. Without an address-model property the binaries are using some compiler default. In your case it turned out to be 32 bit.

At the same time, without address-model property present boost_install doesn't know what if the binary is 32 or 64 bits. So, it assumes 64 bit (a reasonable assumption in 2026).

[fxcoudert]

Since part of the build chain knows that the address-model is 32-bit, as you displayed, why doesn't the other part use that information? Otherwise, what is the correct "architecture" for wasm32 and how should it be detected or set?

[grisumbras]

I think, we used to set these defaults separately, but it caused problems, so we changed it. Now either we deduce both address model and architecture, or we deduce none.

As for the wasm32 architecture, arguably there should be such a thing in b2, but I don't believe we have it.