cmocka needs to add -fstack-protector-strong to link flags

[evanmiller (Evan Miller)]

Noticed this while developing brlaser but I didn't think it was a problem until I tried port install cmocka:

:info:build /opt/local/bin/gcc-mp-7 -pipe -Os -DNDEBUG -I/opt/local/include -arch ppc -mmacosx-version-min=10.4 -dynamiclib -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -current_version 0.7.0 -o libcmocka.0.7.0.dylib -install_name /opt/local/lib/libcmocka.0.dylib CMakeFiles/cmocka.dir/cmocka.c.o
:info:build Undefined symbols:
:info:build   "___stack_chk_fail", referenced from:
:info:build       _vcm_print_error in cmocka.c.o
:info:build       _vprint_message in cmocka.c.o
:info:build       _vprint_error in cmocka.c.o
:info:build       _add_symbol_value in cmocka.c.o
:info:build       __expect_check in cmocka.c.o
:info:build       _get_symbol_value in cmocka.c.o
:info:build       __mock in cmocka.c.o
:info:build       __assert_in_set in cmocka.c.o
:info:build       __assert_not_in_set in cmocka.c.o
:info:build       __test_free in cmocka.c.o
:info:build       _cmocka_run_one_test_or_fixture in cmocka.c.o
:info:build       __check_expected in cmocka.c.o
:info:build       __cmocka_run_group_tests in cmocka.c.o
:info:build       __run_test in cmocka.c.o
:info:build       __run_group_tests in cmocka.c.o
:info:build   "___stack_chk_guard", referenced from:
:info:build       ___stack_chk_guard$non_lazy_ptr in cmocka.c.o
:info:build      (maybe you meant: ___stack_chk_guard$non_lazy_ptr)
:info:build ld: symbol(s) not found
:info:build collect2: error: ld returned 1 exit status

It's a Tiger system which is often/usually relevant:

:debug:main Starting logging for cmocka @1.1.5_0
:debug:sysinfo Mac OS X 10.4.11 (darwin/8.11.0) arch powerpc
:debug:sysinfo MacPorts 2.7.1
:debug:sysinfo Xcode 2.5
:debug:sysinfo SDK 10.4
:debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.4

Full log to follow.

[evanmiller (Evan Miller)]

Main log

[kencu (Ken)]

I see this sometimes too. It is supposed to be tested for and used only if available, but is not always.

Let's see if we can find the library that supplies that symbol in the gcc libraries...I think it is there on Tiger somewhere but have to check. Perhaps it's just a missing link library.

If it doesn't exist at all on Tiger that's another pathway.

[kencu (Ken)]

10.6 (libgcc11):

$ nm -a libssp.0.dylib | grep stack
000000000000141b T ___stack_chk_fail
00000000000020a0 S ___stack_chk_guard

[kencu (Ken)]

next would be to see if libgcc7 on Tiger has the same library (I recall it does) with the same symbol (I recall it does) and then if all that is true, run your link with -Wl,-v added to see if it is trying to link in the needed library.

If it is not -- that is where we need to look.

If it is, why is not failing if it doesn't find it?

[kencu (Ken)]

Of course, you can brute-force it by adding the needed library to the link command. Something like this should presumably work:

configure.ldflags-append -lssp

but that is kinda cheating :>

[kencu (Ken)]

for interest, the link flags that get automatically added by gcc are controlled in this file in the gcc source code:

gcc/config/darwin.h

There are all kinds of various system checks and workarounds in there for various things. It is easy to imagine that whatever is supposed to control the automatic linking of libssp whenever -fstack-protector-strong is used is hosed on Tiger, because almost nobody ever tests Tiger any more.

Iain told me that Tiger is now officially off his regular gcc test suite list, although he won't purposefully try to break Tiger.

[evanmiller (Evan Miller)]

It looks like this is supposed to be controlled at GCC's own configure-time with TARGET_LIBC_PROVIDES_SSP being set when __stack_chk_fail is found. However when I configure gcc7 manually, both with itself and with gcc-apple-4.2, I see

checking __stack_chk_fail in target C library... checking for __stack_chk_fail... no
no __stack_chk_fail on this target
no

I'd need to kick off a full build to see if that result is different in the MP build environment. If so we can either hunt down the bug or inject gcc_cv_libc_provides_ssp=no into GCC's configure env. Since it's such a PITA to re-compile, maybe slip the (hypothetical) fix into the next rev-bump....

[kencu (Ken)]

You can't easily inject stuff like that into gcc's configure environment. It will not respond (never has in the past).

see this:

​https://github.com/gcc-mirror/gcc/blob/b2d961e7342b5ba4e57adfa81cb189b738d10901/gcc/config/darwin.h#L223

where:

      %(link_ssp) \

is added to the link libraries. Now we have to find out where

      %(link_ssp) \

gets defined,and make it right for Tiger.

[kencu (Ken)]

Yeah, I see here in configure.ac

​https://github.com/gcc-mirror/gcc/blob/b2d961e7342b5ba4e57adfa81cb189b738d10901/gcc/configure.ac#L5759

like you say.

Why is it not working right now as it is? It looks like it should be. Something is screwy.

[kencu (Ken)]

ancient relevant message

​https://gcc.gnu.org/legacy-ml/gcc-patches/2005-08/msg00223.html

[kencu (Ken)]

using apple-gcc42 on a simple hello, world c program we see this:

$ gcc-apple-4.2 -Wl,-v  -fstack-protector -o hello1 hello.c
collect2 version 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_16) (i686 Darwin)
/opt/local/libexec/apple-gcc42/gcc/i686-apple-darwin8/4.2.1/ld -dynamic -arch i386 -macosx_version_min 10.4 -weak_reference_mismatches non-weak -o hello1 -lcrt1.o -L/opt/local/lib/apple-gcc42/gcc/i686-apple-darwin8/4.2.1 -L/opt/local/lib/apple-gcc42/gcc/i686-apple-darwin8/4.2.1/../../.. -v /var/tmp//ccX0kwXv.o -lssp_nonshared -lssp -lgcc_s.10.4 -lgcc -lSystem
@(#)PROGRAM:ld  PROJECT:ld64-97.17
configured to support archs: i386 x86_64 ppc ppc64 armv6 armv7
Library search paths:
	/opt/local/lib/apple-gcc42/gcc/i686-apple-darwin8/4.2.1
	/opt/local/lib/apple-gcc42
	/usr/lib
	/usr/local/lib
Framework search paths:
	/Library/Frameworks/
	/System/Library/Frameworks/
ld: library not found for -lssp_nonshared
collect2: ld returned 1 exit status

so in this case, the gcc configuration has correctly noticed that the libssp is needed on this system, it has correctly added the proper library links to the link line, but the libraries, at least one of them, are not there to link against, as presumably they are supposed to be on this system.

[kencu (Ken)]

using gcc7 works perfectly, however:

$ gcc-mp-7 -fstack-protector  -o hello1 hello.c
$ ./hello1
Hello, world!

and in detail:

$ gcc-mp-7 -Wl,-v -fstack-protector  -o hello1 hello.c
collect2 version 7.5.0
/opt/local/bin/ld -dynamic -arch i386 -macosx_version_min 10.4 -weak_reference_mismatches non-weak -o hello1 -lcrt1.o -L/opt/local/lib/gcc7/gcc/i386-apple-darwin8/7.5.0 -L/opt/local/lib/gcc7/gcc/i386-apple-darwin8/7.5.0/../../.. -v /var/tmp//ccAoTpiI.o -lssp_nonshared -lssp -lgcc_s.10.4 -lgcc_ext.10.4 -lgcc -lSystem
@(#)PROGRAM:ld  PROJECT:ld64-97.17
configured to support archs: i386 x86_64 ppc ppc64 armv6 armv7
Library search paths:
	/opt/local/lib/gcc7/gcc/i386-apple-darwin8/7.5.0
	/opt/local/lib/gcc7
	/usr/lib
	/usr/local/lib
Framework search paths:
	/Library/Frameworks/
	/System/Library/Frameworks/
 /opt/local/bin/nm -n /var/tmp//ccAoTpiI.o

so what we have here then is there is apparently nothing wrong with gcc7, or apple-gcc42, regarding the configuration or linkages, but it looks at the moment like apple-gcc42 has either not built or not included the libssp* libraries when building on Tiger.

This is no surprise, really. They were probably just forgotten. If you read through the build_gcc script on the apple-gcc42 port they do a lot of monkeying around with libraries to make them fat, and I think they just plainly forgot to put them in (or left them out on purpose).

[kencu (Ken)]

stack-protector-strong works too:

$ gcc-mp-7 -Wl,-v -fstack-protector-strong  -o hello1 hello.c
collect2 version 7.5.0
/opt/local/bin/ld -dynamic -arch i386 -macosx_version_min 10.4 -weak_reference_mismatches non-weak -o hello1 -lcrt1.o -L/opt/local/lib/gcc7/gcc/i386-apple-darwin8/7.5.0 -L/opt/local/lib/gcc7/gcc/i386-apple-darwin8/7.5.0/../../.. -v /var/tmp//ccTyyx7f.o -lssp_nonshared -lssp -lgcc_s.10.4 -lgcc_ext.10.4 -lgcc -lSystem
@(#)PROGRAM:ld  PROJECT:ld64-97.17
configured to support archs: i386 x86_64 ppc ppc64 armv6 armv7
Library search paths:
	/opt/local/lib/gcc7/gcc/i386-apple-darwin8/7.5.0
	/opt/local/lib/gcc7
	/usr/lib
	/usr/local/lib
Framework search paths:
	/Library/Frameworks/
	/System/Library/Frameworks/
 /opt/local/bin/nm -n /var/tmp//ccTyyx7f.o

[evanmiller (Evan Miller)]

If you see the original report I was using GCC7. It's possible that GCC7 is optimizing out the stack protection calls in hello.c, and that a larger program will be needed to reproduce the issue.

[kencu (Ken)]

The link library was properly included on the link line, and found. So all the gcc7 configuration, knowing it needs libssp, and adding it to the link is all working perfectly.

It must be something else.

Can you show your actual failing link line? We have to see what the real issue is here. (Well, you did, but I mean show the actual -Wl,-v link line).

Perhaps some links are using nostdlibs and not including lssp for Tiger (who would?).

[kencu (Ken)]

For example, in perl they were removing /opt/local/lib* from the link paths to prevent an issue that happened in old times.

So no wonder it couldn't find libssp -- it was being specifically told not to look where it was.

[evanmiller (Evan Miller)]

I uploaded the full log at the beginning - do you want me to clean and build with different linker flags?

[kencu (Ken)]

When you get your link error, and it fails again, please go into the build at the exact folder where it happens, and run the link command manually with the same exact invocation, but add -Wl,-v to the link command line.

You should get a spew of output, and hopefully something in it might give us a clue why the link library pathway to where libssp lives is not available to the linker when looking for libssp.

By default, gcc7 will add the proper path to libssp, as we see above. So my guess at the moment is that something must be stopping it (somehow) from doing that.

Exactly what is TBA...

[evanmiller (Evan Miller)]

Following your instructions, before the undefined symbol error I see

/opt/local/bin/gcc-mp-7 -pipe -Os -DNDEBUG -I/opt/local/include -arch ppc -mmacosx-version-min=10.4 -dynamiclib -Wl,-v -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -current_version 0.7.0 -o libcmocka.0.7.0.dylib -install_name /opt/local/lib/libcmocka.0.dylib CMakeFiles/cmocka.dir/cmocka.c.o
collect2 version 7.5.0
/opt/local/bin/ld -dynamic -dylib -dylib_current_version 0.7.0 -arch ppc -dylib_install_name /opt/local/lib/libcmocka.0.dylib -macosx_version_min 10.4 -weak_reference_mismatches non-weak -o libcmocka.0.7.0.dylib -ldylib1.o -L/opt/local/lib -L/opt/local/lib/gcc7/gcc/ppc-apple-darwin8/7.5.0 -L/opt/local/lib/gcc7/gcc/ppc-apple-darwin8/7.5.0/../../.. -v -headerpad_max_install_names -headerpad_max_install_names CMakeFiles/cmocka.dir/cmocka.c.o -lgcc_s.10.4 -lgcc_ext.10.4 -lgcc -lSystemStubs -lSystem -lef_ppc
@(#)PROGRAM:ld  PROJECT:ld64-97.17
configured to support archs: i386 x86_64 ppc ppc64 armv6 armv7
Library search paths:
    /opt/local/lib
    /opt/local/lib/gcc7/gcc/ppc-apple-darwin8/7.5.0
    /opt/local/lib/gcc7
    /usr/lib
    /usr/local/lib
Framework search paths:
    /Library/Frameworks/
    /System/Library/Frameworks/

So it looks like the search paths are correct but -lssp is not being passed in for whatever reason.

[kencu (Ken)]

I don't see -fstack-protector-strong on that gcc7 link line...can you add it manually and see if that brings happiness?

[kencu (Ken)]

This looks like it is going to turn out to be an issue where the project doesn't add the CFLAGS or CXXFLAGS to the LDFLAGS.

Most systems gloss by it, unawares. But systems like Tiger show up these warts, and I guess for that reason, if no other, it's good to run these builds past Tiger.

[evanmiller (Evan Miller)]

Links without error after adding -fstack-protector-strong to that line.

[kencu (Ken)]

great! we don't have to go spare reconfiguring and rebuilding gcc!

So upstream needs to fix their LDFLAGS to match (include) whichever flags are adding -fstack-protector-strong, presumably CFLAGS.

[evanmiller (Evan Miller)]

Very good, I will get an upstream PR moving...

[evanmiller (Evan Miller)]

Opened: ​https://gitlab.com/cmocka/cmocka/-/merge_requests/42