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

[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: unassigned@gcc.gnu.org
        ReportedBy: ramon.garcia.freesw@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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |jakub at gcc dot gnu.org
         Resolution|                            |INVALID

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-12-30 21:09:11 UTC ---
No, this is a user error.  If you've installed those shared libraries into a
non-standard /opt/gcc-4.6/lib, you need to ensure that the dynamic linker will
find them, i.e. add /opt/gcc-4.6/lib into your LD_LIBRARY_PATH env var you use
for compilation, or on Linux you can add /etc/ld.so.conf.d/*.conf file and run
ldconfig to find them there, etc.

[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 <ramon.garcia.freesw at gmx dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |

--- Comment #2 from Ramón García <ramon.garcia.freesw at gmx dot com> 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 <ramon.garcia.freesw at gmx dot com> 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.