Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 508852 (PR61164) - [4.9/5] sys-devel/gcc-4.9.0 - libitm fails to build with fortify enable
Summary: [4.9/5] sys-devel/gcc-4.9.0 - libitm fails to build with fortify enable
Alias: PR61164
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
Depends on:
Blocks: fortify-source 508418
  Show dependency tree
Reported: 2014-04-27 09:40 UTC by Magnus Granberg
Modified: 2016-01-12 16:01 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

Disable fortify in libitm (53_all_libitm-no-fortify-source.patch,739 bytes, patch)
2014-04-27 09:44 UTC, Magnus Granberg
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Magnus Granberg gentoo-dev 2014-04-27 09:40:10 UTC
When fortify is enable gcc 4.9 fail to build the itm lib with
sys-include -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libitm -I/var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libitm/config/linux/x86 -I/var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libitm/config/linux -I/var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libitm/config/x86 -I/var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libitm/config/posix -I/var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libitm/config/generic -I/var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libitm -mrtm -pthread -Wall -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -pipe -O2 -march=core2 -D_GNU_SOURCE -MT useraction.lo -MD -MP -MF .deps/useraction.Tpo -c /var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libitm/ -o useraction.o >/dev/null 2>&1
mv -f .deps/sanitizer_libignore.Tpo .deps/sanitizer_libignore.Plo
/bin/sh ../libtool --tag=CXX   --mode=compile /var/tmp/portage/sys-devel/gcc-4.9.0/work/build/./gcc/xgcc -shared-libgcc -B/var/tmp/portage/sys-devel/gcc-4.9.0/work/build/./gcc -nostdinc++ -L/var/tmp/portage/sys-devel/gcc-4.9.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/var/tmp/portage/sys-devel/gcc-4.9.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/portage/sys-devel/gcc-4.9.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include    -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS  -I. -I/var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libsanitizer/sanitizer_common -I..  -I /var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libsanitizer/include -isystem /var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libsanitizer/include/system  -Wall -W -Wno-unused-parameter -Wwrite-strings -
pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include     -I../../libstdc++-v3/include/x86_64-pc-linux-gnu     -I/var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libsanitizer/../libstdc++-v3/libsupc++ -DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I /var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libsanitizer/../libbacktrace -I ../libbacktrace -I /var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libsanitizer/../include -include /var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libsanitizer/libbacktrace/backtrace-rename.h -pipe -O2 -march=core2 -D_GNU_SOURCE -MT sanitizer_linux.lo -MD -MP -MF .deps/sanitizer_linux.Tpo -c -o sanitizer_linux.lo /var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libsanitizer/sanitizer_common/
libtool: compile:  /var/tmp/portage/sys-devel/gcc-4.9.0/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.9.0/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libquadmath -I /var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libquadmath/../include -g -pipe -O2 -march=core2 -m32 -MT math/ctanq.lo -MD -MP -MF math/.deps/ctanq.Tpo -c /var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libquadmath/math/ctanq.c -o math/ctanq.o >/dev/null 2>&1
In file included from /usr/include/stdio.h:937:0,
                 from /var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libitm/
/usr/include/bits/stdio2.h: In function ‘void GTM::gtm_verror(const char*, __va_list_tag*)’:
/usr/include/bits/stdio2.h:124:1: error: inlining failed in call to always_inline ‘int vfprintf(FILE*, const char*, __va_list_tag*)’: function body can be overwritten at link time
 vfprintf (FILE *__restrict __stream,
/var/tmp/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/libitm/ error: called from here
   vfprintf (stderr, fmt, list);
Makefile:517: recipe for target 'util.lo' failed
make[4]: *** [util.lo] Error 1
make[4]: *** Waiting for unfinished jobs....

Debian/Ubuntu have disable fortify in there patchset for gcc 4.9.0 and lib itm
Comment 1 Magnus Granberg gentoo-dev 2014-04-27 09:44:04 UTC
Created attachment 375832 [details, diff]
Disable fortify in libitm

We disable fortify as Debian/Ubuntu do but it need to be fixed.
Comment 2 Rafał Mużyło 2014-04-27 12:01:27 UTC
So, out of curiosity, is this a bootstrap problem ?

That is, is this failure caused by something like bug 365015 and once gcc 4.9.0 is built, it can build itself without stumbling into this ?
Comment 3 Magnus Granberg gentoo-dev 2014-04-27 15:33:44 UTC
(In reply to Rafał Mużyło from comment #2)
> So, out of curiosity, is this a bootstrap problem ?
> That is, is this failure caused by something like bug 365015 and once gcc
> 4.9.0 is built, it can build itself without stumbling into this ?
it is gcc 4.9.0 (xgcc) that is trying to build the itm lib
Comment 4 Ryan Hill (RETIRED) gentoo-dev 2014-04-27 15:58:26 UTC
This might be fallout from;a=commit;h=f0d26d578d94a3fafc81d191d2168ab3517b3f0e

Does reverting that help?
Comment 5 Magnus Granberg gentoo-dev 2014-04-27 16:03:39 UTC
Portage 2.2.10 (hardened/linux/amd64, gcc-4.8.2, glibc-2.19, 3.13.9-hardened x86_64)
System uname: Linux-3.13.9-hardened-x86_64-Intel-R-_Core-TM-_i7_CPU_Q_720_@_1.60GHz-with-gentoo-2.2
KiB Mem:     8114608 total,    523960 free
KiB Swap:          0 total,         0 free
Timestamp of tree: Sun, 27 Apr 2014 15:15:01 +0000
ld GNU ld (GNU Binutils) 2.24
app-shells/bash:          4.2_p47
dev-java/java-config:     2.2.0
dev-lang/python:          2.6.9, 2.7.6, 3.2.5-r3, 3.3.5, 3.4.0
dev-util/pkgconfig:       0.28-r1
sys-apps/baselayout:      2.2
sys-apps/openrc:          0.12.4
sys-apps/sandbox:         2.6-r1
sys-devel/autoconf:       2.13, 2.69
sys-devel/automake:       1.8.5-r4, 1.9.6-r3, 1.11.6, 1.12.6, 1.13.4, 1.14.1
sys-devel/binutils:       2.24-r2
sys-devel/gcc:            4.4.4-r2, 4.5.3-r2, 4.6.4, 4.7.3, 4.8.2
sys-devel/gcc-config:     1.8
sys-devel/libtool:        2.4.2
sys-devel/make:           4.0-r1
sys-kernel/linux-headers: 3.14 (virtual/os-headers)
sys-libs/glibc:           2.19
CFLAGS="-pipe -O2 -march=core2"
CXXFLAGS="-pipe -O2 -march=core2"
Comment 6 Magnus Granberg gentoo-dev 2014-04-27 21:15:40 UTC
(In reply to Ryan Hill from comment #4)
> This might be fallout from
> h=f0d26d578d94a3fafc81d191d2168ab3517b3f0e
> Does reverting that help?
Still the same error
Comment 7 Jana Saout 2014-05-08 23:45:53 UTC
There is something weird going on with glibc's "__fortify_function" define.

It complains about problems inlining the fortification wrapper functions from C++ mode.

When I replace "__fortify_function" by "__fortify_function inline" in /usr/include/bits/stdio2.h, the libitm subdirecty compiles.

It will quickly fail in other directories complaining about duplicate "inline" keywords.

So apparently, the macros should have figured out to add "inline" to the list of keywords, but for some unknown reason it fails for the "libitm" subdirectory.

It's kind of hard to follow how the __fortify_function macro is actually expanded in what situation. It depends on the compiler mode or if C or C++ and whether GNU mode is used and so on...

AFAICT the "always_inline" gcc extension is supposed to be used in C mode, and a simple "inline" in c++. Maybe related to the way the compiler is called, a special mode used during gcc building that only enables partial features. (e.g. libitm is written in C++, but doesn't need libstdc++)

I guess libitm defines some preprocessor things that throw off glibc because it assumes fortification is not enabled by default or something. Haven't tried to chase down the exact cause.
Comment 8 Jana Saout 2014-05-09 00:16:02 UTC
Just checked, a preprocessor run reveils that __fortify_function is turned into a simple "extern" only in libitm, no signs of any inlining keyword...
Comment 9 Ryan Hill (RETIRED) gentoo-dev 2014-05-13 04:49:43 UTC
Strange, I looked at a few different files that use vfprintf and the definition of __fortify_function is the same for all.

The declaration of vfprintf however is missing an __inline keyword in libitm.
Comment 11 SpanKY gentoo-dev 2016-01-12 16:01:33 UTC
should be fixed for gcc-6.  we're still carrying Ryan's no-fortify patch until then.  nothing left for us here.