"readelf -d main | grep TEXTREL" returns the same text on both musl and glibc containers:

0x0000000000000016 (TEXTREL) 0x0
0x000000000000001e (FLAGS) TEXTREL

"gcc -no-pie" is another workaround for musl container like Rich said. But I think that 'set(CMAKE_EXE_LINKER_FLAGS "-static")' will be best cross platform solution. As I know "-static" implies "no-pie".

> i'm also surprised that it was only a warning, i think gcc default pie toolchain passes -z text nowadays exactly to make this a link time failure. this is probably a gentoo toolchain bug.

What do you mean "-z text"? We can report improvement for gentoo.

чт, 30 янв. 2020 г. в 00:10, Szabolcs Nagy <nsz@port70.net>:

* Rich Felker <dalias@libc.org> [2020-01-29 15:53:30 -0500]:
> On Wed, Jan 29, 2020 at 09:41:46PM +0300, Андрей Аладьев wrote:
> > So I think that bug is inside musl itself. Glibc container is the same
> > situation works fine. I see no way to create a workaround for this issue.
>
> musl only has limited support for TEXTRELs as a legacy feature, and
> only on some archs. It does not support them in PIE executables or
> other "new settings".

i would like to see why this works on glibc.

glibc can process some text relocs but even then
the elf image will not be shared when multiple
instances of the same binary are executed
potentially wasting a lot of ram and icache.

so i don't think the glibc behaviour is desirable.

if the glibc binary does not have textrel (it can
be checked using readelf -d binary) it would be
nice to know why.

i'm also surprised that it was only a warning,
i think gcc default pie toolchain passes -z text
nowadays exactly to make this a link time failure.
this is probably a gentoo toolchain bug.