error loading shared libraries - BOILER=yes

[Alan DeKok]

Matthew Newton wrote:
> HEAD of master, building with BOILER=yes (without BOILER=yes is fine), I get:
> 
> freeradius-server$ echo BOILER=yes >> Make.inc.in
> freeradius-server$ ./configure --prefix=/opt/fr3
> freeradius-server$ make
> 
> freeradius-server$ build/bin/radiusd -X
> FreeRADIUS Version 3.0.0, for host x86_64-unknown-linux-gnu, built on Feb 11 2012 at 02:40:47
> Copyright (C) 1999-2009 The FreeRADIUS server project and contributors. 
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A 
> PARTICULAR PURPOSE. 
> You may redistribute copies of FreeRADIUS under the terms of the 
> GNU General Public License v2. 
>  
> Errors reading /opt/fr3/etc/raddb: No such file or directory

  Well... yes.  The path to raddb is hard-coded into the binary.  If
you're running it from the build directory, it doesn't really know that.

  The solution is "radiusd -Xd ./raddb -n debug"

  See raddb/debug.conf for a description of why "-n debug" helps.

> freeradius-server$ build/bin/relink/radiusd -X
> build/bin/relink/radiusd: error while loading shared libraries: libfreeradius-radius.so: cannot open shared object file: No such file or directory
> 
> ...OK - probably looking in /opt/fr3/lib

  Yes.  The "-n debug" helps.

> freeradius-server$ make install
> ...
> 
> freeradius-server$ build/bin/radiusd -X
> ...as above, OK

  Which isn't changed by a "make install"

> freeradius-server$ cd /opt/fr3/sbin
> 
> sbin$ ./radiusd -X
> ./radiusd: error while loading shared libraries: build/lib/relink/.libs/rlm_acctlog.so: cannot open shared object file: No such file or directory
> 
> ... not good.

  Yup.  I'll have to go fix that.  I don't normally install it for my
testing, so that might have slipped through the cracks.

> 
> The problem seems to be in the final 'gcc -rdynamic -o build/bin/relink/radiusd'
> command - if you remove all the many
> ' -Wl,-rpath=/opt/fr3/lib build/lib/relink/.libs/rlm_acctlog.so' 
> arguments and run manually, then copy the resulting binary to the correct
> location, all is fine. The dynamic libs seem to be being added to gcc by
> $${${1}_R_PRLIBS} in scripts/libtool.mk:106, and previously :205, but before
> that I get a bit lost :-)

  I think you're right.  I'll take a look.

  The PRLIBS stuff is there for Mac, which *does* require the binary to
be told where the libaries live.  <sigh> Like the dynamic linker can't
find libraries?

  Alan DeKok.