Blender Binary is getting to big - linking error due to out-of-range addresses #113892

New Issue

Bastien Montagne · 2023-10-18T15:57:10+02:00

Bastien Montagne commented

2023-10-18 15:57:10 +02:00

Currently when trying to build main in DEBUG with ASAN enabled and most features enabled, one will run into this type of errors when linking final binary:

mold: error: /usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o:(.text): relocation R_X86_64_32S against .tm_clone_table out of range: 2147741344 is not in [-2147483648, 2147483648)

This blog post seems to give a good comprehensive overview of the issue.

There are at least three ways to address this issue.

1. Reduce binary size - disabling ASAN

Disabling ASAN for parts of the code makes building successful again. E.g. in !113891, ASAN is disabled by default for all of our extern libraries.

2. Reduce binary size - Move some dependencies to shared libraries.

We are still linking statically against many pre-compiled libraries (from lib/linux_x86_64_glibc_228/), moving more of these to dynamic linking would likely help.

Some libraries from our extern source-code folder could also potentially be built and linked as shared libraries.

3. Embrace the binary size - move to `medium` or `large`.

In theory, there are options (like the -mcmodel for GCC) to build binaries supporting larger address range than the one allowed by int32. I could not get neither medium nor large data model to work from quick testing, but I suspect it's because pre-compiled libraries would also need to be built with these settings.

Don't think we should consider this option unless the first two ones cannot solve well enough the issue though.

Currently when trying to build main in DEBUG with ASAN enabled and most features enabled, one will run into this type of errors when linking final binary: ``` mold: error: /usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o:(.text): relocation R_X86_64_32S against .tm_clone_table out of range: 2147741344 is not in [-2147483648, 2147483648) ``` [This blog post](https://maskray.me/blog/2023-05-14-relocation-overflow-and-code-models) seems to give a good comprehensive overview of the issue. There are at least three ways to address this issue. ### 1. Reduce binary size - disabling ASAN Disabling ASAN for parts of the code makes building successful again. E.g. in !113891, ASAN is disabled by default for all of our `extern` libraries. ### 2. Reduce binary size - Move some dependencies to shared libraries. We are still linking statically against many pre-compiled libraries (from `lib/linux_x86_64_glibc_228/`), moving more of these to dynamic linking would likely help. Some libraries from our `extern` source-code folder could also potentially be built and linked as shared libraries. ### 3. Embrace the binary size - move to `medium` or `large`. In theory, there are options (like the `-mcmodel` for GCC) to build binaries supporting larger address range than the one allowed by `int32`. I could not get neither `medium` nor `large` data model to work from quick testing, but I suspect it's because pre-compiled libraries would also need to be built with these settings. Don't think we should consider this option unless the first two ones cannot solve well enough the issue though.

Bastien Montagne added the

Type

Design

label 2023-10-18 15:57:10 +02:00

Bastien Montagne referenced this issue

2023-10-18 15:57:31 +02:00

Fix linking errors when doing full debug build with ASAN: Disable ASAN for `extern`. #113891

Bastien Montagne added the