Impossible to compile with -D__BLST_NO_ASM__ on x86_64

[dannywillems]

I am trying to compile master like this:

./build.sh -D__BLST_NO_ASM__

It looks like it is enough to compile blst without any ASM. However, on x86_64, I have got this error:

➜  blst git:(master) ./build.sh -D__BLST_NO_ASM__       
+ cc -O -fno-builtin -fPIC -Wall -Wextra -Werror -D__ADX__ -D__BLST_NO_ASM__ -mno-avx -c ./src/server.c
In file included from ./src/vect.c:10,
                 from ./src/server.c:22:
./src/no_asm.h: In function ‘mul_mont_n’:
./src/no_asm.h:18:5: error: unknown type name ‘llimb_t’; did you mean ‘limb_t’?
   18 |     llimb_t limbx;
      |     ^~~~~~~
      |     limb_t
./src/no_asm.h:23:24: error: ‘llimb_t’ undeclared (first use in this function); did you mean ‘limb_t’?
   23 |         limbx = (mx * (llimb_t)a[i]) + hi;
      |                        ^~~~~~~
      |                        limb_t
./src/no_asm.h:23:24: note: each undeclared identifier is reported only once for each function it appears in
./src/no_asm.h:23:32: error: expected ‘)’ before ‘a’
   23 |         limbx = (mx * (llimb_t)a[i]) + hi;
      |                 ~              ^
      |                                )
./src/no_asm.h:25:29: error: right shift count >= width of type [-Werror=shift-count-overflow]
   25 |         hi = (limb_t)(limbx >> LIMB_T_BITS);
[...]

[dot-asm]

Well, it's kind of intentional. Thing is that it's specifically the assembly build that undergoes the validation process. Or in other words non-assembly build doesn't actually come with a formal correctness guarantee. For this reason it's argued that __BLST_NO_ASM__ on x86_64 [and aarch64 for that matter] is actually unjustified. So just don't;-)

Of course one can argue that the error message could have been more meaningful. For example

#if LIMB_T_BITS==32
typedef unsigned long long llimb_t;
#else
# error "unsupported configuration"
#endif

Would it be helpful?

[dot-asm]

In context of cross-reference to #69, describe your problem specifically on s390x.

[dot-asm]

I'm closing this assuming that it's related to #100. If not, just describe the problem and reopen.