Bug 544278 – sys-libs/glibc-2.20-r2 with -fno-stack-protector in CXXFLAGS: librtld.os: In function `lookup_doit': rtld.c:(.text+0x136): undefined reference to `__stack_chk_fail_local'

• Status: RESOLVED NEEDINFO
• Product: Gentoo Linux

[Description Andrew Savchenko 2015-03-23 23:30:36 UTC]

Hello,

glibc-2.20-r2 fails to build with:

i686-pc-linux-gnu-gcc  -Wl,-O1,--as-needed -Wl,-O1,--as-needed  -nostdlib -nostartfiles -shared -o /var/tmp/portage/sys-libs/glibc-2.20-r2/work/build-x86-i686-pc-linux-gnu-np
tl/elf/ld.so.new                \
          -Wl,-z,combreloc -Wl,-z,relro -Wl,-z,defs -Wl,-z,now  \
          /var/tmp/portage/sys-libs/glibc-2.20-r2/work/build-x86-i686-pc-linux-gnu-nptl/elf/librtld.os -Wl,--version-script=/var/tmp/portage/sys-libs/glibc-2.20-r2/work/build
-x86-i686-pc-linux-gnu-nptl/ld.map              \
          -Wl,-soname=ld-linux.so.2                     \
          -Wl,-defsym=_begin=0
/var/tmp/portage/sys-libs/glibc-2.20-r2/work/build-x86-i686-pc-linux-gnu-nptl/elf/librtld.os: In function `lookup_doit':
rtld.c:(.text+0x136): undefined reference to `__stack_chk_fail_local'
/var/tmp/portage/sys-libs/glibc-2.20-r2/work/build-x86-i686-pc-linux-gnu-nptl/elf/librtld.os: In function `process_dl_debug':
rtld.c:(.text+0x5ea): undefined reference to `__stack_chk_fail_local'
/var/tmp/portage/sys-libs/glibc-2.20-r2/work/build-x86-i686-pc-linux-gnu-nptl/elf/librtld.os: In function `print_statistics':
rtld.c:(.text+0xc31): undefined reference to `__stack_chk_fail_local'
/var/tmp/portage/sys-libs/glibc-2.20-r2/work/build-x86-i686-pc-linux-gnu-nptl/elf/librtld.os: In function `.L215':
rtld.c:(.text+0x3193): undefined reference to `__stack_chk_fail_local'
/var/tmp/portage/sys-libs/glibc-2.20-r2/work/build-x86-i686-pc-linux-gnu-nptl/elf/librtld.os: In function `.L1055':
rtld.c:(.text+0x4691): undefined reference to `__stack_chk_fail_local'
/var/tmp/portage/sys-libs/glibc-2.20-r2/work/build-x86-i686-pc-linux-gnu-nptl/elf/librtld.os:dl-load.c:(.text+0x49c6): more undefined references to `__stack_chk_fail_local' f
ollow
/usr/lib/gcc/i686-pc-linux-gnu/4.9.2/../../../../i686-pc-linux-gnu/bin/ld: /var/tmp/portage/sys-libs/glibc-2.20-r2/work/build-x86-i686-pc-linux-gnu-nptl/elf/ld.so.new: hidden
 symbol `__stack_chk_fail_local' isn't defined
/usr/lib/gcc/i686-pc-linux-gnu/4.9.2/../../../../i686-pc-linux-gnu/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

[Comment 1 Andrew Savchenko 2015-03-23 23:31:11 UTC]

Created attachment 399574 [details]
emerge --info sys-libs/glibc

[Comment 2 Andrew Savchenko 2015-03-23 23:32:12 UTC]

Created attachment 399576 [details]
build.log.xz

[Comment 3 Andrew Savchenko 2015-03-23 23:32:31 UTC]

Created attachment 399578 [details]
environment

[Comment 4 Andrew Savchenko 2015-03-24 00:44:03 UTC]

I have the same problem with 2.20 and 2.19-r1.

[Comment 5 Andrew Savchenko 2015-03-24 00:49:03 UTC]

Looks like stack-protector fired up, this is bad...

[Comment 6 SpanKY 2015-03-24 01:49:49 UTC]

my guess is your ridiculous CFLAGS are causing it to break.  can you try with simple ones instead ?
  CFLAGS="-march=native -O2 -pipe"

[Comment 7 Andrew Savchenko 2015-03-24 02:16:38 UTC]

(In reply to SpanKY from comment #6)
> my guess is your ridiculous CFLAGS

But they're not ridiculous and can be grounded.

>  are causing it to break.  can you try
> with simple ones instead ?
>   CFLAGS="-march=native -O2 -pipe"

I tried 2.20-r2 with these CFLAGS, the same failure.

Please looked into build.log I uploaded. CFLAGS are stripped down to "-O2 -march=native" already. For gcc this is done in the eclass.

[Comment 8 SpanKY 2015-03-24 03:57:12 UTC]

(In reply to Andrew Savchenko from comment #7)

your flags are ridiculous.  the glibc ebuild does strip them down, but not entirely.  if you look closer at the log, you'll see some leak through.

i see now your LDFLAGS are also invalid.  change them to:
  LDFLAGS='-Wl,-O1 -Wl,--as-needed'

try turning off ccache/distcc to see if that makes a difference.  and try with blank LDFLAGS and the simple suggested CFLAGS.

[Comment 9 Andrew Savchenko 2015-03-25 09:19:15 UTC]

(In reply to SpanKY from comment #8)
> (In reply to Andrew Savchenko from comment #7)
> 
> your flags are ridiculous.

Please read -O3 flag expansion in man gcc before claiming this (most extra flags are from there).

> the glibc ebuild does strip them down, but not
> entirely.  if you look closer at the log, you'll see some leak through.
> 
> i see now your LDFLAGS are also invalid.  change them to:
>   LDFLAGS='-Wl,-O1 -Wl,--as-needed'

Please read carefully what I posted above.

As can be seen from comment 1, for gcc LDFLAGS are set to "-Wl,-O1,--as-needed" despite system defaults (this is done via package.env)

As can be seen from comment 7, I tried CFLAGS="-march=native -O2 -pipe" (together with simple LDFLAGS above) with negative result.

> try turning off ccache/distcc to see if that makes a difference.  and try
> with blank LDFLAGS and the simple suggested CFLAGS.

ccache and distcc have nothing to do here. I actually found a reason: "-fno-stack-protector" in CXXFLAGS (not CFLAGS) caused this failure.

Before claiming this bug as INVALID, please consider that "-fno-stack-protector" was added to flags as was recommended in the news "2014-06-15  GCC 4.8.3 defaults to -fstack-protector", because I'm not happy with stack-protector enabled by default on this host.

[Comment 10 SpanKY 2015-03-25 19:18:37 UTC]

(In reply to Andrew Savchenko from comment #9)

your settings are ridiculous, end of story.  your LDFLAGS are invalid (we do not support combined flags in LDFLAGS in flag-o-matic) and you need to fix them.

i did not say this report was invalid.  if i did, i would have closed it already.  it's also why i kept asking you to try things to narrow it down (because you have too much noise).  if you want to be hostile, then i will punt the report.

CXXFLAGS shouldn't be impacting the build ... that's weird.

[Comment 11 SpanKY 2015-03-25 22:14:08 UTC]

(In reply to Andrew Savchenko from comment #9)

i can't reproduce this behavior.  please post a full build log with ccache & distcc turned off with the minimal set of CFLAGS/CXXFLAGS/LDFLAGS flags that cause the issue to show up on your system.

[Comment 12 Andrew Savchenko 2015-03-29 06:53:46 UTC]

Strange, after I was able to build 2.20-r2 as described above (and have it installed), I can't reproduce this issue any longer.

[Comment 13 SpanKY 2015-03-30 21:55:56 UTC]

i looked through the source and couldn't find any place where CXXFLAGS would matter.  they get used by a few tests, but not during normal configure/make -- everything is asm/C in glibc.

oh well, if it comes up again, try finding a minimal flag set and re-open.