Current blender has developed a 32bit antipathy

Building Blender
1

Due to:

[  195s] /home/abuild/rpmbuild/BUILD/blender-2.92~git.20201106T085505.60ad4a761ac/source/blender/blenlib/intern/session_uuid.c: In function 'BLI_session_uuid_generate':
[  195s] /home/abuild/rpmbuild/BUILD/blender-2.92~git.20201106T085505.60ad4a761ac/source/blender/blenlib/intern/session_uuid.c:39:18: error: implicit declaration of function 'atomic_add_and_fetch_uint64'; did you mean 'atomic_add_and_fetch_uint32'? [-Werror=implicit-function-declaration]
[  195s]    39 |   result.uuid_ = atomic_add_and_fetch_uint64(&global_session_uuid.uuid_, 1);
[  195s]       |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~
[  195s]       |                  atomic_add_and_fetch_uint32
[  195s] cc1: some warnings being treated as errors
[  195s] make[2]: *** [source/blender/blenlib/CMakeFiles/bf_blenlib.dir
/build.make:1034: source/blender/blenlib/CMakeFiles/bf_blenlib.dir/intern/session_uuid.c.o] Error 1
[  195s] make[2]: Leaving directory '/home/abuild/rpmbuild/BUILD/blender-2.92~git.20201106T085505.60ad4a761ac/build'
[  195s] make[1]: *** [CMakeFiles/Makefile2:5753: source/blender/blenlib/CMakeFiles/bf_blenlib.dir/all] Error 2
[  195s] make[1]: *** Waiting for unfinished jobs....

While it is arguable, how much sense a 32bit build makes today, it’s a regression nevertheless.

2

AFAIK 32 bit support was removed some versions ago, not sure 2.83 LTS is 32bit compatible

3

That is not a 32bit problem. The error is

error: implicit declaration of function

Which is to say, a function was not declared before use.

4

In this case it actually is related. That function is declared and defined; only on 64bit builds however :slight_smile:

Because 32bit builds have officially been dropped I’m not sure if this is a “patches are welcome” situation or not. That uuid field needs to be 64bits and looks like updating it needs to be atomic… might be difficult to do on a 32bit arch but haven’t researched in depth.

2 Likes
5

It is, even though we no longer do CI on 32 bit, regressions like this can happen (also DNA regressions we didn’t pick up on) patches are welcome, same way we accept fixes for platforms we don’t ship our selves (like haiku-os).

1 Like
6

Digging a bit deeper reveals…

in ./source/blender/makesdna/DNA_session_uuid_types.h:

typedef struct SessionUUID {
  /* Never access directly, as it might cause a headache when more bits are needed: if the field
   * is used directly it will not be easy to find all places where partial access is used. */
  uint64_t uuid_;
} SessionUUID;

and that uint64_t nature is rather deeply entangled in ./source/blender/blenlib/{BLI_session_uuid.h,intern/session_uuid.c}.

Hence, while intern/atomic/atomic_ops.h provides register size agnostic atomic functions, it would involve quite some churn in the former modules to implement the uuid this way.

Guess, we should say good bye to 32 bit builds…

7

If i were looking to work around this issue, i’d probably add the missing atomic functions and implement them with some kind of lock (they seem like relatively quick operations, spinlock will probably do the trick)

8

or even port the code to https://en.cppreference.com/w/cpp/atomic/atomic.

9

That’ll be a little trickier, the atomics library is currently a header only C library, while adding a C++ backend surely isn’t impossible but it’ll be more work to keep it working for C code.

Another option is given that most of these are lifted from jemalloc is see if they have a solution already.

10

Even jemalloc comes with c11 atomics, while the generic gcc and msvc variants take a significantly more advanced approach nowadays (macro based function generation).

11

Possible fix here:
https://developer.blender.org/D9577