[Bug driver/80836] final binaries missing rpath despite all attempts to use the appropriate -Wl,-rpath= statement

[rjvbertin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80836

René J.V. Bertin <rjvbertin at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Host|                            |linux

--- Comment #4 from René J.V. Bertin <rjvbertin at gmail dot com> ---
I've been trying to get this right, but without luck. In my latest attempt I
had -Wl,-rpath statements in BOOT_LDFLAGS as well as in LDFLAGS during the
configure, make and "make install" steps and I also configured them using
--with-stage1-ldflags . Yet my binaries didn't contain any rpath information at
all.

I don't think it's such an uncommon situation to build gcc for installation
somewhere other than /usr. Non-privileged users may build for installation
under their home directory, and what's more, a standard (64bit) build on Ubuntu
will apparently put the runtime libraries into /usr/lib64 or /usr/local/lib64,
which is NOT a system standard location.

There should really be a reliable and easily accessible method to achieve this:

--with-stdlib-rpaths : add the stdlib (libgcc_s, libstdc++, libfortran etc)
paths to the RPATH of the generated executable (including the GCC executables)
--with-rpaths : build the GCC executables and libraries with the paths to all
dependencies stored in the RPATH.

I think those are the 2 distinct aspects of the issue, but I'm not certain it's
justified not to handle them with a single option.

FWIW, this is all not an issue on Mac where dependencies are stored with their
full path by default. A hassle sometimes, but most of the time it makes life a
lot easier.