gcc.jam sets LD_LIBRARY_PATH which breaks FreeBSD build

[pisymbol@…]

In build/tools/v2/tools/gcc.jam we are setting the LD_LIBRARY_PATH for compilation to:

/usr/bin:/usr/lib:/usr/lib32:/usr/lib64

Couple of points:

• /usr/bin (?) :D
• /usr/lib on FreeBSD does not contain major number libs so most if not all binaries will not pick up anything from here
• /usr/lib32 on FreeBSD DOES CONTAIN major number libs so if you are building on 32-bit this will work, HOWEVER if you are building 64-bit then this will cause failures
• /usr/lib64 does not exist on FreeBSD (I believe this is a Linux thing)

Based on the comments within gcc.jam I FEEL as do some other people (see thread reference) that if bjam is *really* going to rely on rtld then it should do so by NOT setting anything to LD_LIBRARY_PATH which many have pointed out is only to be used when the standard search path is not enough. Setting this PATH is very dangerous and for 99% of the build cases, rtld does the right thing.

Thread:

​http://www.nabble.com/Boost-1.36.0-FreeBSD-patches-for-review-td20143328.html

If it is decided to set LD_LIBRARY_PATH then we need to make this OS specific and unset it for FreeBSD (or minimally add back /lib which Steven pointed out in the above thread is probably not the right solution given LD_LIBRARY_PATH's semantics).

[Vladimir Prus]

I'll try to sort this, one way or another, soonish.

[jim@…]

I have no input on the right way to fix it, but as a point of reference, this fix-up in gcc.jam works for 64-bit FreeBSD. See today's trunk test results (http://www.boost.org/development/tests/trunk/jc-bell.com_FBSDA.html).

local lib_path = $(root)/bin $(root)/lib $(root)/lib64 /lib ;

For FreeBSD-64, yanking $(root)/lib32 and adding /lib is req'd, or at least putting /lib before $(root)/lib32. Glad to try other things if you want.