On 2012-Feb-21 17:00:53 -0500, Diane Bruce <d...@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 <ka...@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 <kab...@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
pgp9kJoRtSEVa.pgp
Description: PGP signature
