Re: rtld or lang/gcc cannot find libgcc_s.so.1

On 2012-Feb-21 17:00:53 -0500, Diane Bruce <db_at_db.net> wrote:
>Or is this another problem? -rpath is added in /usr/ports/Mk

This may help for applications built wihin the ports framework but
doesn't help if you want to use gcc46 as a general purpose compiler.

On 2012-Feb-21 23:03:27 -0500, Benjamin Kaduk <kaduk_at_MIT.EDU> wrote:
>How would things break if we made everything in the base system specify 
>-rpath of /lib and /usr/lib as appropriate, and then put the ports 
>versions first in the default search path?

I have a nasty feeling this would break i386 emulation on amd64 - if the
i386 executable has an embedded rpath pointing to /lib, it will fail to
find the shared libraries in /lib32.

On 2012-Feb-21 20:16:12 -0500, Alexander Kabaev <kabaev_at_gmail.com> wrote:
>Just changing the compiler to supply rpath on binaries it builds might
>be safer approach. Various GCC builds on Solaris (OpenCSW, Sunfreeware,
>etc) are doing this for ages and mostly manage to pull things off.

I agree this is the way to go.  I tried suggesting this in
ports/142226 but it got closed without actually fixing the problem.

(IMO, the whole -rpath approach is backwards - in virtually all cases,
if you link against a library at a specific path, you are going want
to run against that library as well so the default should be to look
there, with something like -rpath only used in the few cases where
that isn't correct).

>Third option is of course purging _all_ toolchain components out of the
>tree, which is such a fine bikeshed material that I am a bit scared to
>bring that up.

One of the big advantages of FreeBSD is that it can recompile itself.
Having to install ports to do this would be a massive step backwards
and wouldn't actually solve the underlying problem unless you were
restricted to having no more than one installed toolchain (which has
other problems).

-- 
Peter Jeremy