http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54732
Bug #: 54732
Summary: [4.8 regression] Installation failure: libbacktrace
rebuilds upon install when built with "make
bootstrap-lean"
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ger...@pfeifer.com
Created attachment 28295
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28295
Log of "make install" on x86_64-suse-linux
This took me a while to track down, and I do not have a fix, but at
least it seems 100% reproducible.
When building with "make bootstrap-lean" as opposed to "make bootstrap"
a plain "make" in the object directory still goes through successfully,
alas a "make install" actually builds things again in libbacktrack.
That, plus is invokes gcc via the regular PATH, not the just built one.
See the following excerpt from a full install log I am attaching:
gmake[2]: Entering directory `/tmp/OBJ-0924-2231/libbacktrace'
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I/home/gp/svn/gcc-HEAD/libbacktrace -I
/home/gp/svn/gcc-HEAD/libbacktrace/../include -I
/home/gp/svn/gcc-HEAD/libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I
../../gcc/include -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-Wcast-qual -Werror -g -O2 -MT dwarf.lo -MD -MP -MF .deps/dwarf.Tpo -c -o
dwarf.lo /home/gp/svn/gcc-HEAD/libbacktrace/dwarf.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/home/gp/svn/gcc-HEAD/libbacktrace
-I /home/gp/svn/gcc-HEAD/libbacktrace/../include -I
/home/gp/svn/gcc-HEAD/libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I
../../gcc/include -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-Wcast-qual -Werror -g -O2 -MT dwarf.lo -MD -MP -MF .deps/dwarf.Tpo -c
/home/gp/svn/gcc-HEAD/libbacktrace/dwarf.c -o dwarf.o
mv -f .deps/dwarf.Tpo .deps/dwarf.Plo
Originally I reported this on i386-unknown-freebsd10.0, which is a nightly
tester I operate, but my tests and the build log confirm the same on
x86_64-suse-linux for example.
The only reason it does not break there is that the system compiler is
sufficiently new not to stumble over the difference versus GCC trunk as
the one on FreeBSD does.
