Re: Auto-rpath revisited...

[Jim Wilson <wilson at cygnus dot com>]

There is no disagreement over the importance of the problem or the need
to fix it.  There is some disagreement I think about what we are discussing.

The original message talked about modifying collect to automatically add
multiple rpath options depending on the -L and -l options passed into collect.
I believe this is unwise, and this is what I am arguing against.  This runs
the risk of breaking build environments for existing projects that already
know how shared libraries are supposed to work.  If you helpfully add -rpath
options to an X11 build, then you are likely to break that X11 build in some
way.

Your message talks about adding a single -rpath option for libstdc++, perhaps
generated by the g++ driver.  I will offer no objection to this if the ldconfig
solution can't work, and there is someway to disable it.  Adding a -rpath
option for libraries that come with egcs isn't going to break other programs,
and will make egcs work better.  This gets us to H.J. Lu's suggestions which
look reasonable to me.  He made two suggestions, modify LIB_SPEC to pass
-rpath for libstdc++, modify g++ driver to pass down --try-rpath option for
libstdc++.  I like the g++ driver change a little better than the LIB_SPEC
change.  There might be portability problems with the g++ driver change though,
since -rpath isn't a universal linker option.  Richard Henderson's extension
of the --try-rpath idea also looked useful.

Jim