Boost no longer builds using toolset=emscripten as of emsdk 4.0.22

[jrxpana]

Environment and version details

• Operating System+version: Windows 11
• Compiler+version: emscripten
• Shell: Windows command prompt, powershell
• B2 Version: <= 1.90.0

Brief problem description

One of the changes in emsdk 4.0.22 was the removal of the em++ and emcc script files (with no extension) in the emsdk distributions for Windows.

Unfortunately, boost seems to use at least one of these files for detection when you use b2.exe to build with toolset=emscripten.

So starting with 4.0.22 our boost builds began to fail unless we manually created an empty emcc and em++ file in the emsdk\upstream\emscripten folder. I suspect we only needed emcc but we created them both just in case because it's really hard to tell what boost is doing when it builds.

I reported this to the emscripten folks but I'm also reporting here because I don't know who should fix this, and for visibility of the workaround (create empty emcc and em++ files).

You should also be aware that emsdk might have additional changes to the emcc files in the near future, because of things like emscripten-core/emscripten#24858

Steps to reproduce the issue

Download emsdk and set up the environment using the following commands:

git clone https://github.com/emscripten-core/emsdk.git
cd emsdk
emsdk install 4.0.22
emsdk activate 4.0.22

Then build boost using b2.exe -a toolset=emscripten target-os=linux address-model=32 and your favorite b2 options.

Actual behavior summary

When the emcc and em++ files are missing, the b2 build output starts like this:

Performing configuration checks

    - default address-model    : none [1]
    - cxx11_hdr_ratio          : no [2]
    - cxx11_hdr_ratio          : no [3]
    - has std::atomic_ref      : no [2]

And various parts of the build fail with errors like:

emscripten.compile.c++ bin.v2\libs\date_time\build\emscripten-1\release\address-model-32\exception-handling-on-js\link-static\runtime-link-static\target-os-linux\threading-multi\visibility-hidden\gregorian\greg_month.o
CreateProcessA() Windows API failed: 2 - The system cannot find the file specified.

    "emcc"   -fvisibility-inlines-hidden -fexceptions -pthread -O3 -Wall -fvisibility=hidden -Wno-inline -m32 -sUSE_PTHREADS -emit-llvm -c -DBOOST_ALL_NO_LIB=1 -DBOOST_COBALT_USE_STD_PMR=1 -DDATE_TIME_INLINE -DNDEBUG   -I"."  -c -o "bin.v2\libs\date_time\build\emscripten-1\release\address-model-32\exception-handling-on-js\link-static\runtime-link-static\target-os-linux\threading-multi\visibility-hidden\gregorian\greg_month.o" "libs/date_time/src/gregorian/greg_month.cpp"

Expected behavior summary

When successful, the b2 build output should start like this:

Performing configuration checks

    - default address-model    : 32-bit [1]
    - default architecture     : none [1]
    - cxx11_hdr_ratio          : yes [2]
    - cxx11_template_aliases   : yes [2]
    - cxx11_decltype           : yes [2]
    - cxx11_char16_t           : yes [2]
    - cxx11_char32_t           : yes [2]
    - has std::atomic_ref      : no [2]

and the build will be successful.

[grisumbras]

I just opened emscripten docs, and the tutorial says

On Windows the tool is called using the slightly different syntax: emcc or em++. The remainder of this tutorial uses the Linux approach (./emcc).

So, the official documentation presumes emcc and em++ are callable.

I found this item in the changelog

The remaining launcher scripts (e.g. emcc.bat) were removed from the git repository. These scripts are created by the ./bootstrap script which must be run before the toolchain is usable (for folks using a git checkout of emscripten).

Maybe that's the source of the problem?

Anyways, if you do have some launcher script, then putting using emscripten : : /path/to/that/script ; (or using emscripten : : that-script ; if it's in PATH) into project-config.jam or user-config.jam, should fix your problem.

[grisumbras]

Also, more configuration information is printed when you invoke b2 with --debug-configuration. And in the build directory (bin.v2 by default) there is a file called config.log. It contains the output of configuration checking commands (you may have to use the flag --reconfigure before checking it).

[jrxpana]

The removal of the emcc and em++ files in the Windows distribution weren't mentioned in the changelog, but they happened with version 4.0.22. The ./bootstrap script doesn't create them either, and in fact you don't even need the bootstrap script if you get the emsdk build directly (as per the instructions in my initial message).

All I can tell you is if the emcc file exists, boost builds fine. If it doesn't exist, the boost build fails. It has nothing to do with the path. If I had to guess, it's because the boost/tools/build/src/tools/emscripten.jam file is explicitly looking for emcc with no extension, but someone with more knowledge of how b2 works would have to take a look.

[jrxpana]

And just for clarity, there used to be 4 different emcc files in the emsdk\upstream\emscripten folder:

• emcc (a shell script)
• emcc.bat
• emcc.ps1
• emcc.py

When you call emcc from whatever terminal/command prompt you're using on Windows, it will decide which file actually gets called based on whatever logic that prompt uses. So for example, if you're running in Powershell, calling emcc will actually call emcc.ps1.

On Windows the actual emcc file (with no extension) was never being called, so I'd guess that's why they removed it. So now there are 3 different emcc files. But from a programmatic standpoint, you can still call emcc and it will work.

[grisumbras]

Okay, so if there's no more such file, we'd have to determine which to use (which is somewhat of a problem, because apparently, it depends on the shell).

But my suggestion how to solve your issue right now still stands. Put using emscripten : : emcc.bat ; (or whatever) into a config file.

[jrxpana]

Yes thanks, I can solve the issue right now by adding using emscripten : : emcc.bat ; to my project-config.jam.

I can also solve it by adding an empty emcc file to my emsdk\upstream\emscripten folder. I just wanted to report this so you could decide how (or if) you want to fix it in the future.