Bug #5676: miniruby linking error: undefined reference to ___stack_chk_guard

• Status: Closed
• Assignee: kosaki (Motohiro KOSAKI)
• Target version: 2.0.0
• ruby -v: ruby 2.0.0dev (2011-11-27 trunk 33861) [i386-cygwin]

[duerst (Martin Dürst)]

I get what I think is a linking error when linking miniruby.
Below is a (shortened) copy of the output I get. This is on
a clean checkout of trunk (using Ruby 1.8.7 as baseruby).

duerst@jougashima /cygdrive/c/Data/ruby-public
$ make
CC = gcc
LD = ld
LDSHARED = gcc -shared -s
CFLAGS = -O3 -g -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Werror=pointer-arith -Werror=write-strings -Werror=declaration-after-statement -Werror=implicit-function-declaration
XCFLAGS = -include ruby/config.h -include ruby/missing.h -D_FORTIFY_SOURCE=2 -fstack-protector -DRUBY_EXPORT
CPPFLAGS = -I. -I.ext/include/i386-cygwin -I./include -I.
DLDFLAGS = -Wl,--enable-auto-image-base,--enable-auto-import -Wl,--out-implib=libruby191.dll.a cygruby191.def -Xlinker --no-undefined
SOLIBS = cygruby191.res.o -lpthread -lrt -ldl -lcrypt
linking miniruby.exe
dmyencoding.o: In function set_encoding_const': /cygdrive/c/Data/ruby-public/encoding.c:1473: undefined reference to ___stack_chk_guard'
/cygdrive/c/Data/ruby-public/encoding.c:1520: undefined reference to ___stack_chk_guard' /cygdrive/c/Data/ruby-public/encoding.c:1520: undefined reference to ___stack_chk_fail'
bignum.o: In function rb_str_to_inum': /cygdrive/c/Data/ruby-public/bignum.c:763: undefined reference to ___stack_chk_guard'
/cygdrive/c/Data/ruby-public/bignum.c:790: undefined reference to ___stack_chk_guard' /cygdrive/c/Data/ruby-public/bignum.c:790: undefined reference to ___stack_chk_fail'
dir.o: In function dir_read': /cygdrive/c/Data/ruby-public/dir.c:569: undefined reference to ___stack_chk_guard'
/cygdrive/c/Data/ruby-public/dir.c:586: undefined reference to ___stack_chk_guard' /cygdrive/c/Data/ruby-public/dir.c:586: undefined reference to ___stack_chk_fail'

[... many more like these ...]

vm_dump.o: In function control_frame_dump': /cygdrive/c/Data/ruby-public/vm_dump.c:27: undefined reference to ___stack_chk_guard'
/cygdrive/c/Data/ruby-public/vm_dump.c:148: undefined reference to ___stack_chk_guard' /cygdrive/c/Data/ruby-public/vm_dump.c:148: undefined reference to ___stack_chk_fail'
cont.o: In function cont_restore_0': /cygdrive/c/Data/ruby-public/cont.c:733: undefined reference to ___stack_chk_guard'
unicode.o: In function onigenc_unicode_property_name_to_ctype': /cygdrive/c/Data/ruby-public/./enc/unicode.c:2087: undefined reference to ___stack_chk_guard'
/cygdrive/c/Data/ruby-public/./enc/unicode.c:2114: undefined reference to ___stack_chk_guard' /cygdrive/c/Data/ruby-public/./enc/unicode.c:2114: undefined reference to ___stack_chk_fail'
collect2: ld returned 1 exit status
make: *** [miniruby.exe] Error 1

duerst@jougashima /cygdrive/c/Data/ruby-public
$

[kosaki (Motohiro KOSAKI)]

• ruby -v changed from ruby 1.8.7 (2008-08-11 patchlevel 72) [i386-cygwin] to -

I get what I think is a linking error when linking miniruby.
Below is a (shortened) copy of the output I get. This is on
a clean checkout of trunk (using Ruby 1.8.7 as baseruby).

duerst@jougashima /cygdrive/c/Data/ruby-public
$ make
       CC

[nobu (Nobuyoshi Nakada)]

• Category set to build
• Status changed from Open to Assigned
• Assignee set to kosaki (Motohiro KOSAKI)
• Target version set to 2.0.0
• ruby -v changed from - to ruby 2.0.0dev (2011-11-27 trunk 33861) [i386-cygwin]

It works fine.

[nobu (Nobuyoshi Nakada)]

The issue occurs on mingw too, and is solved by the patch.
But miniruby.exe still can't execute.
miniruby.exe: error while loading shared libraries: libssp-0.dll: cannot open shared object file: No such file or directory

I think -fstack-protector is too problematic and not worth on mingw.

[kosaki (Motohiro KOSAKI)]

• Status changed from Assigned to Closed

r33863

[jonforums (Jon Forums)]

I've recently adopted FreeBSD 9.0 (in my "A New Year, A New OS" resolution) and have apparently run into this problem on trunk when trying to build with the non-default gcc-4.6.2 package. The issue goes away when I remove -fstack-protector from XCFLAGS.

As I'm new to FreeBSD so this may simply be my misconfiguration, but has anyone successfully built trunk with the gcc-4.6.2 package?

BTW, why isn't TRY_LD_FLAGS also used in https://github.com/ruby/ruby/blob/trunk/configure.in#L506-508 (I tried it but it doesn't solve the failure)

== BUILD FAILURE ===

pkg_info | grep gcc
gcc-4.6.2           GNU Compiler Collection 4.6

git log -3 --oneline
e0f059a * 2012-02-18
ace4630 * lib/fileutils.rb: refactored FileUtil methods to use the `define_command` API...
92e7c2d * ext/dbm/extconf.rb: remove dbm.

gcc46 --version
gcc46 (FreeBSD Ports Collection) 4.6.2

../configure --enable-shared --disable-install-doc --with-gcc=gcc46
...
make
...
linking miniruby
dmyencoding.o: In function `set_encoding_const':
/home/jon/rubydev/ruby-git/build/../encoding.c:1525: undefined reference to `__stack_chk_fail_local'
bignum.o: In function `rb_str_to_inum':
/home/jon/rubydev/ruby-git/build/../bignum.c:790: undefined reference to `__stack_chk_fail_local'
dir.o: In function `dir_read':
/home/jon/rubydev/ruby-git/build/../dir.c:586: undefined reference to `__stack_chk_fail_local'
dir.o: In function `dir_each':
/home/jon/rubydev/ruby-git/build/../dir.c:623: undefined reference to `__stack_chk_fail_local'
dir.o: In function `glob_helper':
/home/jon/rubydev/ruby-git/build/../dir.c:1475: undefined reference to `__stack_chk_fail_local'
io.o:/home/jon/rubydev/ruby-git/build/../io.c:9639: more undefined references to `__stack_chk_fail_local' follow
/usr/local/bin/ld: miniruby: hidden symbol `__stack_chk_fail_local' isn't defined
/usr/local/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
*** Error code 1

[nobu (Nobuyoshi Nakada)]

• Status changed from Closed to Feedback

The symbol in question differs, so sounds like a runtime library mismatch.
Does it fail with the default package?

If it occurs only with the non-default, and also simplified code without ruby, it should be reported to the gcc team.

[naruse (Yui NARUSE)]

FYI, I could build ruby on FreeBSD 9.0 amd64 with gcc 4.6 in ports.

[jonforums (Jon Forums)]

Thanks for checking. Trunk builds fine using the old default gcc 4.2.1 and configure adds -fstack-protector to Makefile.

I think you're right on runtime library mismatch, but shouldn't it fail when miniruby is used later in the build process, not at miniruby link time? The following sequence definitely looks like a library mismatch...

ldconfig -rv | grep gcc
	search directories: /lib:/usr/lib:/usr/lib/compat:/usr/local/lib:/usr/local/lib/compat/pkg:/usr/local/lib/gcc46:/usr/local/lib/nss:/usr/local/lib/pth:/usr/local/lib/qt4:/usr/local/lib/zsh
	33:-lgcc_s.1 => /lib/libgcc_s.so.1
	...
	475:-lssp.0 => /usr/local/lib/gcc46/libssp.so.0

ldconfig -rv | grep ssp
	35:-lssp.0 => /lib/libssp.so.0
	475:-lssp.0 => /usr/local/lib/gcc46/libssp.so.0

diff -q /lib/libssp.so.0 /usr/local/lib/gcc46/libssp.so.0
Files /lib/libssp.so.0 and /usr/local/lib/gcc46/libssp.so.0 differ

stat -f '%z' /lib/libssp.so.0 /usr/local/lib/gcc46/libssp.so.0 
6828
26880

objdump -tT /usr/local/lib/gcc46/libssp.so.0 | grep __stack_chk_fail
00000ba0 l     F .text	00000019              __stack_chk_fail_local
00000b40 g     F .text	00000028              __stack_chk_fail
00000b40 g    DF .text	00000028  LIBSSP_1.0  __stack_chk_fail

objdump -tT /lib/libssp.so.0 | grep __stack_chk_fail
00000fc0 g    DF .text	00000027  LIBSSP_1.0  __stack_chk_fail

But shouldn't gcc46's default search dirs save the link like it appears to be happening when configure (using --with-gcc=gcc46) executes RUBY_TRY_CFLAGS(-fstack-protector, ...)?

gcc46 -print-search-dirs 
install: /usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.0/4.6.2/
programs: =/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd9.0/4.6.2/:/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd9.0/4.6.2/:/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd9.0/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.0/4.6.2/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.0/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.0/4.6.2/../../../../../i386-portbld-freebsd9.0/bin/i386-portbld-freebsd9.0/4.6.2/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.0/4.6.2/../../../../../i386-portbld-freebsd9.0/bin/
libraries: =/usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.0/4.6.2/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.0/4.6.2/../../../../../i386-portbld-freebsd9.0/lib/i386-portbld-freebsd9.0/4.6.2/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.0/4.6.2/../../../../../i386-portbld-freebsd9.0/lib/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.0/4.6.2/../../../i386-portbld-freebsd9.0/4.6.2/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.0/4.6.2/../../../:/lib/i386-portbld-freebsd9.0/4.6.2/:/lib/:/usr/lib/i386-portbld-freebsd9.0/4.6.2/:/usr/lib/

I've overlooked something important or a FreeBSD post-install step after running sudo pkg_add -r gcc-4.6.2. Back to the RTFM-a-thon unless you guys spot my mistake.

[nobu (Nobuyoshi Nakada)]

• Status changed from Feedback to Closed

Jon Forums wrote:

I think you're right on runtime library mismatch, but shouldn't it fail when miniruby is used later in the build process, not at miniruby link time?

The mismatch between the compiler and the runtime library. It can't be deferred.

475:-lssp.0 => /usr/local/lib/gcc46/libssp.so.0

Then -fstack-protector should let gcc link that library.

Try "gcc46 -dumpspecs | grep -A1 '^\*link_ssp:'", and if %{fstack-protector:} does not exist or no options is given after the colon, the spec is wrong. And you will see same error with the following simple code and -fstack-protector option, I guess:

#include <stdlib.h>
#include <stdio.h>
int main() {printf("%p\n", alloca(102400)); return 0;}

If it's the case, this is primarily an issue of FreeBSD port.

But shouldn't gcc46's default search dirs save the link like it appears to be happening when configure (using --with-gcc=gcc46) executes RUBY_TRY_CFLAGS(-fstack-protector, ...)?

It shouild be done in the spec file, as metioned above.