Hi Diomidis, > When glibc is compiled with emscripten toolchain for compiling to asm.js > and WebAssembly [1] (e.g. as part of groff),
You mean gnulib, not glibc? glibc is not built when you compile groff. > the compilation fails due > to the inclusion of assembly code, as shown in the example below. > > emcc groff.bc -o groff.html > In function vasnprintf() > void (i16*)* asm sideeffect "fnstcw $0", "=*m" > LLVM ERROR: asm() with non-empty content not supported, use EM_ASM() > (see emscripten.h) > > The following small change corrects this problem. > > --- a/lib/fpucw.h 2019-10-12 15:27:25.810899880 +0300 > +++ b/lib/fpucw.h 2019-10-12 14:25:30.875463263 +0300 > @@ -62,7 +62,7 @@ > */ > > /* Inline assembler like this works only with GNU C. */ > -#if (defined __i386__ || defined __x86_64__) && defined __GNUC__ > +#if (defined __i386__ || defined __x86_64__) && defined __GNUC__ && > !defined __EMSCRIPTEN__ > > typedef unsigned short fpucw_t; /* glibc calls this fpu_control_t */ This indicates that in the compilation, at this point, either the macro __i386__ or __x86_64__ is defined as a preprocessor macro. When you run $ touch empty.c; emcc -E -dM empty.c |grep '\(i386\|x86_64\)' does is display such macro definitions? If yes, your emcc compiler is misconfigured. For me, it does not define __i386__ or __x86_64__; it defines __asmjs__ instead. If not, it means that some file defines __i386__ or __x86_64__ during the compilation. But application files should not do this. In this case, your groff.bc (or one of the files that it includes directly or indirectly) is buggy. Bruno
