Re: [clisp-list] compile on i686 issue for advice/comment please

[Kaz K. <ka...@ky...>]

On 2025-08-16 05:37, C Habs wrote:
> Hello clisp-list
> 
> Trying to compile latest clisp  ( that checked out from the master branch
> on gitlab).
> The computer (laptop) is a [old] linux 32bit  celeron M 440  (slackware).
> 
> All dependencies present (i think).
> 
> The problem seems to be when using the flag, --with-threads=POSIX_THREADS
> as without it, all compiles through.
> 
> With the flag the build bails out at 'configure' time.
> 
> Question [firstly I suppose]:  does 'threads' only work on  64 bit arch,
> because there seems to be no trouble on 64 bit arch   ?
> 
> If the above is a 'yes', then no need to go further perhaps.
> 
> Question:  what is spvw.'x'  (.d .c etc)  doing and why is it an issue on
> 32 bit arch ?

spvw.d is the file from which I learned the unforgettable German word for
memory management: speicherverwaltung. 
 
> Question:  the error reported,  is the issue clear and is there a solution
> ?     (i'm not a 'c' or expert coder or familiar with clisp code, so  I
> dont know what to make of it).

This one:

../src/lispbibl.d:7598:15: error: size of array ‘symbol_size_check’ is negative
 7598 |   typedef int symbol_size_check[1 - 2 * (int)(sizeof(symbol_) % varobject_alignment)];
      |  　            ^~~~~~~~~~~~~~~~~

is using an array declaration hack to implement a compile time sanity check:

  typedef int size_check[1 - 2 * CONSTANT_EXPR_THAT_MUST_BE_ZERO]

If CONSTANT_EXPR_THAT_MUST_BE_ZERO is nonzero, size_check is declared
as an array type with a negative dimension, violating an ISO C constraint,
requiring a diagnostic. Most compilers will treat that as a fatal error,
aborting compilation.

In this case, the expression that must be zero is checking that
the sizeof the type symbol_ is a multiple of varobject_alignment.

That not being the case is pointing to some inconsistency in
the configuration: a mismatch between how the content of symbol_
is defined relative to how varobject_alignment is defined.


In addition, the following is probably okay, but could benefit from
modernization:

../src/spvw.d:968:3: warning: ignoring return value of ‘__builtin_alloca’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
  968 |   alloca(1);                    /* Makes this function non-inlinable. */
      |   ^~~~~~~~~~~~~~~~~~~
make: *** [Makefile:1133: spvw.o] Error 1

E.g. define a "notinline" macro like this:

#if __GNUC__
#define noinline __attribute__((noinline))
#else
#define noinline
#endif

notinline void my_function_that_should_not_be_inlined(void)
{
   ...
}

The compiler is noticing that the return value of alloca(1) isn't
being captured and would be justified in optimizing it away,
subsequently allowing the function to be inlined.