Bug #5676

miniruby linking error: undefined reference to ___stack_chk_guard

Added by Martin Dürst over 2 years ago. Updated about 2 years ago.

[ruby-core:41317]
Status:Closed
Priority:Normal
Assignee:Motohiro KOSAKI
Category:build
Target version:2.0.0
ruby -v:ruby 2.0.0dev (2011-11-27 trunk 33861) [i386-cygwin] Backport:

Description

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 -DFORTIFYSOURCE=2 -fstack-protector -DRUBYEXPORT
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
stackchkguard'
/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
stackchkfail'
bignum.o: In function rb_str_to_inum':
/cygdrive/c/Data/ruby-public/bignum.c:763: undefined reference to
stackchkguard'
/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
stackchkfail'
dir.o: In function dir_read':
/cygdrive/c/Data/ruby-public/dir.c:569: undefined reference to
stackchkguard'
/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
stackchk_fail'

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

vmdump.o: In function control_frame_dump':
/cygdrive/c/Data/ruby-public/vm_dump.c:27: undefined reference to
stackchkguard'
/cygdrive/c/Data/ruby-public/vmdump.c:148: undefined reference to `_stackchkguard'
/cygdrive/c/Data/ruby-public/vm
dump.c:148: undefined reference to `
stackchkfail'
cont.o: In function cont_restore_0':
/cygdrive/c/Data/ruby-public/cont.c:733: undefined reference to
stackchkguard'
unicode.o: In function onigenc_unicode_property_name_to_ctype':
/cygdrive/c/Data/ruby-public/./enc/unicode.c:2087: undefined reference to
stackchkguard'
/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
_stackchk_fail'
collect2: ld returned 1 exit status
make: *** [miniruby.exe] Error 1

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

History

#1 Updated by Motohiro KOSAKI over 2 years ago

  • 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

#2 Updated by Nobuyoshi Nakada over 2 years ago

  • Category set to build
  • Status changed from Open to Assigned
  • Assignee set to 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.

#3 Updated by Nobuyoshi Nakada over 2 years ago

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.

#4 Updated by Motohiro KOSAKI over 2 years ago

  • Status changed from Assigned to Closed

#5 Updated by Jon Forums about 2 years ago

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
stackchkfaillocal'
bignum.o: In function `rb
strtoinum':
/home/jon/rubydev/ruby-git/build/../bignum.c:790: undefined reference to `
stackchkfaillocal'
dir.o: In function dir_read':
/home/jon/rubydev/ruby-git/build/../dir.c:586: undefined reference to
stackchkfaillocal'
dir.o: In function dir_each':
/home/jon/rubydev/ruby-git/build/../dir.c:623: undefined reference to
stackchkfaillocal'
dir.o: In function `glob
helper':
/home/jon/rubydev/ruby-git/build/../dir.c:1475: undefined reference to `
stackchkfaillocal'
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
stackchkfaillocal' isn't defined
/usr/local/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
*** Error code 1

#6 Updated by Nobuyoshi Nakada about 2 years ago

  • 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.

#7 Updated by Yui NARUSE about 2 years ago

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

#8 Updated by Jon Forums about 2 years ago

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:-lgccs.1 => /lib/libgccs.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 _stackchkfail
00000ba0 l F .text 00000019 _
stackchkfaillocal
00000b40 g F .text 00000028 _
stackchkfail
00000b40 g DF .text 00000028 LIBSSP1.0 _stackchkfail

objdump -tT /lib/libssp.so.0 | grep _stackchkfail
00000fc0 g DF .text 00000027 LIBSSP
1.0 _stackchk_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.

#9 Updated by Nobuyoshi Nakada about 2 years ago

  • 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
#include
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.

Also available in: Atom PDF