Make -fstack-protector work w/o passing it in LDFLAGS #18

New Issue

claunia · 2026-01-29T22:23:17Z

claunia commented

2026-01-29 22:23:17 +00:00

Originally created by @SilvanScherrer on GitHub (Jan 28, 2020).

if -fstack-protection is used while compiling I guess -lssp should automatically be added to the LDFLAGS. IIRC it was the case with gcc4.

Originally created by @SilvanScherrer on GitHub (Jan 28, 2020). if -fstack-protection is used while compiling I guess -lssp should automatically be added to the LDFLAGS. IIRC it was the case with gcc4.

claunia commented

2026-01-29 22:23:19 +00:00

@dmik commented on GitHub (Apr 7, 2020):

It's not even that, the problem is bigger. Stack protection needs a review. Given this sample code:

#include <stdlib.h>
int main(int argc, const char **argv)
{
  int * i2 = alloca (100);
  return i2 [10];
}

the compile and link command gcc -Zomf -fstack-protector sandbox.c fails with:

weakld: cannot open library file '\@unixroot\usr\lib\ssp_nonshared_s.a'.
emxomfld: weak prelinker failed. (rc=8)

I.e. for some reason gcc wants a non-shared version which we don't provide (at least not in RPM).

The compile command gcc -c -Zomf -fstack-protector sandbox.c works but a subsequent link command gcc -Zomf sandbox.o fails with:

weakld: error: Unresolved symbol (UNDEF) '___stack_chk_guard'.
weakld: info: The symbol is referenced by:
    D:\Coding\Tests\sandbox.o
weakld: error: Unresolved symbol (UNDEF) '___stack_chk_fail'.
weakld: info: The symbol is referenced by:
    D:\Coding\Tests\sandbox.o
Ignoring unresolved externals reported from weak prelinker.
Error! E2028: ___stack_chk_guard is an undefined reference
Error! E2028: ___stack_chk_fail is an undefined reference
file D:\Coding\Tests\sandbox.o(sandbox.o): undefined symbol ___stack_chk_guard
file D:\Coding\Tests\sandbox.o(sandbox.o): undefined symbol ___stack_chk_fail

This is expected as the linker needs -fstack-protector as well. Once we add this option to the above link command, we will get the same error about the missing ssp_nonshared_s.a library as the above. The only link command that works here afterwards is this one:

gcc -Zomf sandbox.o -lssp0.dll

This is certainly not the right flow of things. We should look into that at some point.

See https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html for GCC docs on that.

@dmik commented on GitHub (Apr 7, 2020): It's not even that, the problem is bigger. Stack protection needs a review. Given this sample code: ```c #include <stdlib.h> int main(int argc, const char **argv) { int * i2 = alloca (100); return i2 [10]; } ``` the compile and link command `gcc -Zomf -fstack-protector sandbox.c` fails with: ``` weakld: cannot open library file '\@unixroot\usr\lib\ssp_nonshared_s.a'. emxomfld: weak prelinker failed. (rc=8) ``` I.e. for some reason gcc wants a non-shared version which we don't provide (at least not in RPM). The compile command `gcc -c -Zomf -fstack-protector sandbox.c` works but a subsequent link command `gcc -Zomf sandbox.o` fails with: ``` weakld: error: Unresolved symbol (UNDEF) '___stack_chk_guard'. weakld: info: The symbol is referenced by: D:\Coding\Tests\sandbox.o weakld: error: Unresolved symbol (UNDEF) '___stack_chk_fail'. weakld: info: The symbol is referenced by: D:\Coding\Tests\sandbox.o Ignoring unresolved externals reported from weak prelinker. Error! E2028: ___stack_chk_guard is an undefined reference Error! E2028: ___stack_chk_fail is an undefined reference file D:\Coding\Tests\sandbox.o(sandbox.o): undefined symbol ___stack_chk_guard file D:\Coding\Tests\sandbox.o(sandbox.o): undefined symbol ___stack_chk_fail ``` This is expected as the linker needs `-fstack-protector` as well. Once we add this option to the above link command, we will get the same error about the missing `ssp_nonshared_s.a` library as the above. The only link command that works here afterwards is this one: ``` gcc -Zomf sandbox.o -lssp0.dll ``` This is certainly not the right flow of things. We should look into that at some point. See https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html for GCC docs on that.

claunia commented

2026-01-29 22:23:19 +00:00

@dmik commented on GitHub (Apr 7, 2020):

Sorry for the hassle and discard the previous comment: it's actually solved by simply doing yum install libssp-devel. It provides all the necessary static libraries and the example compiles and links w/o errors.

@SilvanScherrer what about your problem, there is no way to achieve what you want if the compile and link steps are run as separate commands — the second invocation doesn't have access to the first invocation's compile options. So the only way to go here is to put -fstack-protector both in CFLAGS and LDFLAGS. This will always work.

Looking at Linux, it looks like __stack_chk_fail is provided by libc. I guess we should do the same to get rid of the whole libssp hassle. No SSP.DLL will be needed (except for the forwarder for old software), no libssp-devel and no -fstack-protector in LDFLAGS. But that's postponed for now.

@dmik commented on GitHub (Apr 7, 2020): Sorry for the hassle and discard the previous comment: it's actually solved by simply doing `yum install libssp-devel`. It provides all the necessary static libraries and the example compiles and links w/o errors. @SilvanScherrer what about your problem, there is no way to achieve what you want if the compile and link steps are run as separate commands — the second invocation doesn't have access to the first invocation's compile options. So the only way to go here is to put `-fstack-protector` both in CFLAGS and LDFLAGS. This will always work. Looking at Linux, it looks like `__stack_chk_fail` is provided by libc. I guess we should do the same to get rid of the whole libssp hassle. No SSP.DLL will be needed (except for the forwarder for old software), no libssp-devel and no `-fstack-protector` in LDFLAGS. But that's postponed for now.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bitwiseworks/gcc-os2#18