[Bug other/51720] New: Build issue. stage1 ldflags not correctly used

[ramon.garcia.freesw at gmx dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51720

 Bug #: 51720
   Summary: Build issue. stage1 ldflags not correctly used
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ramon.garcia.fre...@gmx.com


In order to build GCC with shared libraries libcloog and libppl, that have been
previously installed in /opt/gcc-4.6/lib, one executes configure with the
following options

../gcc-4.6.2/configure --prefix=/opt/gcc-4.6 --with-ppl=/opt/gcc-4.6
--with-cloog=/opt/gcc-4.6 --enable-gold --enable-languages=c,c++,ada,fortran,go
-with-stage1-ldflags="-Wl,-rpath=/opt/gcc-4.6/lib -static-libgcc
-static-libstdc++" --with-boot-ldflags="-Wl,-rpath=/opt/gcc-4.6/lib 
-static-libgcc -static-libstdc++"

But the compiler built in the stage1 phase does not find libppl and libcloog:

> ./gcc/cc1
./gcc/cc1: error while loading shared libraries: libcloog.so.0: cannot open
shared object file: No such file or directory

becuase the stage1 ldflags are not correctly passed

The issue comes from the top level Makefile. The invocation of the stage1 build
correctly passes stage1 ldflags as part of the HOST_EXPORTS. But in the submake
invocation, it also passes $(BASE_FLAGS_TO_PASS), that sets LDFLAGS to empty,
and has higher priority.


.PHONY: all-stage1-gcc maybe-all-stage1-gcc
.PHONY: clean-stage1-gcc maybe-clean-stage1-gcc
maybe-all-stage1-gcc:
maybe-clean-stage1-gcc:
maybe-all-stage1-gcc: all-stage1-gcc
all-stage1: all-stage1-gcc
TARGET-stage1-gcc = $(TARGET-gcc)
all-stage1-gcc: configure-stage1-gcc
@[ $(current_stage) = stage1 ] || $(MAKE) stage1-start
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
TFLAGS="$(STAGE1_TFLAGS)"; \
$(HOST_EXPORTS)  \
cd $(HOST_SUBDIR)/gcc && \
$(MAKE) $(BASE_FLAGS_TO_PASS) \
CFLAGS="$(STAGE1_CFLAGS)" \
CXXFLAGS="$(STAGE1_CXXFLAGS)" \
LIBCFLAGS="$(LIBCFLAGS)" \
CFLAGS_FOR_TARGET="$(CFLAGS_FOR_TARGET)" \
CXXFLAGS_FOR_TARGET="$(CXXFLAGS_FOR_TARGET)" \
LIBCFLAGS_FOR_TARGET="$(LIBCFLAGS_FOR_TARGET)" \
$(EXTRA_HOST_FLAGS)  $(EXTRA_GCC_FLAGS) \
TFLAGS="$(STAGE1_TFLAGS)" \
$(TARGET-stage1-gcc)


Suggestions:

a) include LDFLAGS="$(STAGE1_LDFLAGS)" in this invocation

b) remove LDFLAGS from BASE_FLAGS_TO_PASS, and include it everywhere it may be
needed. So LDFLAGS setting from HOST_EXPORTS will take priority

[Bug other/51720] Build issue. stage1 ldflags not correctly used

[ramon.garcia.freesw at gmx dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51720

Ramón García  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #2 from Ramón García  
2011-12-30 23:05:23 UTC ---
The option --with-stage1-ldflags is a documented option of the GCC build
process that is not being processed correctly. From the installation
instructions (install/configure.html from the source tree):

--with-stage-1dflags=flags
   This option may be used to set linker flags to be used when linking
stage 1 of GCC. These are also used when linking GCC if configured
with --disable-bootstrap. By default no special flags are used.   

There are other reasons for using this build option, perhaps compiling with
some vendor linker or operating system needs it. In fact, the option is
processed, but incorrectly, as I explained. The generated Makefile contains 

STAGE1_LDFLAGS = -Wl,-rpath=/opt/gcc-4.6/lib -static-libgcc -static-libstdc++

and the speficication for the target

all-gcc-stage1: 
$(HOST_EXPORTS)  
...

The variable HOST_EXPORTS passes settings such as  LDFLAGS=$(STAGE1_LDFLAGS) to
the stage1. But the make invocation contains a command line settings that takes
higher priority.

In summary, this is a case of a documented option that is not being correctly
handled.

[Bug other/51720] Build issue. stage1 ldflags not correctly used

[ramon.garcia.freesw at gmx dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51720

--- Comment #3 from Ramón García  
2011-12-30 23:24:42 UTC ---
Note that I am reporting this bug to help other users have less problems. I
have fixed the issue for myself (the workaround, editing Makefile, is not too
difficult). I took the time to isolate the problem, for the benefit of the GCC
development team and the community.