Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Feb 2012 07:02:30 +1100
From:      Peter Jeremy <peterjeremy@acm.org>
To:        freebsd-current@freebsd.org, freebsd-ports@freebsd.org
Subject:   Re: rtld or lang/gcc cannot find libgcc_s.so.1
Message-ID:  <20120222200230.GA7631@server.vk2pj.dyndns.org>
In-Reply-To: <20120221201612.2968c810@kan.dyndns.org>
References:  <20120221182850.GA20768@troutmask.apl.washington.edu> <20120221185754.GL55074@deviant.kiev.zoral.com.ua> <20120221194259.GA21185@troutmask.apl.washington.edu> <20120221201612.2968c810@kan.dyndns.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2012-Feb-21 17:00:53 -0500, Diane Bruce <db@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@MIT.EDU> wrote:
>How would things break if we made everything in the base system specify=20
>-rpath of /lib and /usr/lib as appropriate, and then put the ports=20
>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@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).

--=20
Peter Jeremy

--r5Pyd7+fXNt84Ff3
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iEYEARECAAYFAk9FSdYACgkQ/opHv/APuIftsACgvVwauLQDiKHRmJHO/2ZlHNX5
MR8AniXHbgrFOY4LyfQyAXveDSlMcaxM
=ixjH
-----END PGP SIGNATURE-----

--r5Pyd7+fXNt84Ff3--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120222200230.GA7631>