Opened 3 years ago
Last modified 3 years ago
#63469 new defect
cmocka needs to add -fstack-protector-strong to link flags
Reported by: | evanmiller (Evan Miller) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.7.1 |
Keywords: | Cc: | kencu (Ken) | |
Port: | cmocka |
Description
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.
Attachments (1)
Change History (26)
Changed 3 years ago by evanmiller (Evan Miller)
Attachment: | cmocka-main.log added |
---|
comment:1 Changed 3 years ago by 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.
comment:2 Changed 3 years ago by kencu (Ken)
10.6 (libgcc11):
$ nm -a libssp.0.dylib | grep stack 000000000000141b T ___stack_chk_fail 00000000000020a0 S ___stack_chk_guard
comment:3 Changed 3 years ago by 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?
comment:4 Changed 3 years ago by 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 :>
comment:5 Changed 3 years ago by 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 every 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.
comment:6 Changed 3 years ago by 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....
comment:7 Changed 3 years ago by 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:
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.
comment:8 Changed 3 years ago by kencu (Ken)
Yeah, I see here in configure.ac
like you say.
Why is it not working right now as it is? It looks like it should be. Something is screwy.
comment:9 Changed 3 years ago by kencu (Ken)
ancient relevant message
https://gcc.gnu.org/legacy-ml/gcc-patches/2005-08/msg00223.html
comment:10 Changed 3 years ago by 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.
comment:11 Changed 3 years ago by 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).
comment:12 Changed 3 years ago by 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
comment:13 Changed 3 years ago by 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.
comment:14 Changed 3 years ago by 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).
comment:15 Changed 3 years ago by 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.
comment:16 Changed 3 years ago by evanmiller (Evan Miller)
I uploaded the full log at the beginning - do you want me to clean and build with different linker flags?
comment:17 Changed 3 years ago by 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...
comment:18 Changed 3 years ago by 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.
comment:19 Changed 3 years ago by 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?
comment:20 Changed 3 years ago by 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.
comment:21 Changed 3 years ago by evanmiller (Evan Miller)
Links without error after adding -fstack-protector-strong
to that line.
comment:22 Changed 3 years ago by 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.
comment:23 Changed 3 years ago by evanmiller (Evan Miller)
Very good, I will get an upstream PR moving...
comment:24 Changed 3 years ago by evanmiller (Evan Miller)
comment:25 Changed 3 years ago by kencu (Ken)
Port: | gcc7 removed |
---|---|
Summary: | gcc @7.5.0_2: Fails to link projects compiled with -fstack-protector-strong → cmocka needs to add -fstack-protector-strong to link flags |
Main log