I'm building some binaries on an ARMv7 build of Alpine, and getting errors about the symbol `__stack_chk_fail` being missing.

Adding `-fno-stack-protector` to my build command solves the issue.

But I wonder if there's a way to get stack protection? I notice that when I do `nm -D /usr/lib/libc.so | grep __stack_chk_fail` I get the output:

```
0003cc48 T __stack_chk_fail
```

So the symbol is there, just not getting linked.

I tried adding each of these to my build command, but none of them seemed to fix the issue (that is, let me build without disabling stack protection):

* -Wl,--whole-archive -lssp_nonshared -Wl,--no-whole-archive
* -static-libgcc
* -Wl,--as-needed -lc

Is there something else I should be trying?

-- 
dubiousjim@gmail.com

On Tue Mar 18, 2025 at 9:59 PM CET, Jim Pryor wrote:
> I'm building some binaries on an ARMv7 build of Alpine, and getting errors about the symbol `__stack_chk_fail` being missing.
>
> Adding `-fno-stack-protector` to my build command solves the issue.
>
> But I wonder if there's a way to get stack protection? I notice that when I do `nm -D /usr/lib/libc.so | grep __stack_chk_fail` I get the output:
>
> ```
> 0003cc48 T __stack_chk_fail
> ```
>
> So the symbol is there, just not getting linked.
>
> I tried adding each of these to my build command, but none of them seemed to fix the issue (that is, let me build without disabling stack protection):
>
> * -Wl,--whole-archive -lssp_nonshared -Wl,--no-whole-archive
> * -static-libgcc
> * -Wl,--as-needed -lc
>
> Is there something else I should be trying?

Do you have any small command that can reproduce the issue?

I tried gcc -o main main.c -fstack-protector-all with a simple test file
and it build fine.

On Tue, Mar 18, 2025, at 5:43 PM, Sertonix wrote:
> Do you have any small command that can reproduce the issue?
>
> I tried gcc -o main main.c -fstack-protector-all with a simple test file
> and it build fine.

Unfortunately I don't have a minimal reproduction. For me the failure came when building the examples/features2 and examples/features3 files in the micropython source tree. This requires having a significant part of the micropython source tree installed (for included headers and makefile pieces). Also the linking is done by the tools/mpy_ld.py file, which uses CPython and the py3-elftools library. So a whole lot of infrastructure. I expect there'd be some way to get a smaller reproduction, but I'm not able to produce it now.

I can build the other example Python C libraries (which the mpy_ld.py tool links into *.mpy files) besides those two, without disabling stack protection. And if I disable stack protection I can build all of them.

-- 
dubiousjim@gmail.com

I realized that it's not surprising that the alternative fixes I mentioned aren't working, since supplying them to the gcc build command isn't going to pass them on to the non-standard linker (the mpy_ld.py script) used in this case. And that tool doesn't have command-line options that look promising. I can hack its source directly though.

The missing symbol is found in the /usr/lib/libc.so file (well, that's a link, but it's found in its target). But that doesn't seem to be linked into the binary that's produced.

There is a /usr/lib/libc.a file. I can look into whether some *.o file extractable from that defines the symbol I'm missing...

-- 
dubiousjim@gmail.com

On Tue, Mar 18, 2025, at 7:00 PM, Jim Pryor wrote:
> There is a /usr/lib/libc.a file. I can look into whether some *.o file 
> extractable from that defines the symbol I'm missing...

If I extract the __stack_chk_fail.lo file from that archive (and also the memcpy.lo file, which it in turn needs a symbol from) and add those two object files along with the project's binaries, then linking works ok and the generated *.mpy library seems to work.

-- 
dubiousjim@gmail.com