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>