Building Samba 3.6.6 on RedHat 5.8. When I try to run the tests (which I do *before* installing anything) it fails. st/s3dc/logs/log.smbd contains: [2012/08/03 12:09:06.502207, 0, pid=12794] param/loadparm.c:7885(lp_set_enum_parm) WARNING: Ignoring invalid value 'vlp' for parameter 'printing' [2012/08/03 12:09:06.503316, 0, pid=12794] smbd/server.c:1109(main) standard input is not a socket, assuming -D option ./bin/smbd: symbol lookup error: ./bin/smbd: undefined symbol: wbcSidsToUnixIds The "undefiend symbol" is because the smbd executable is trying to use the libwbclient.so.0 which is in place from a previous installation. It's getting it via the RPATH setting in the binary. (If that weren't set it wouldn't find the library at all). But the test should be running with the version of that library which has just been built. So the test need to set LD_LIBRARY_PATH to the appropriate value for that to happen, either globally for the test or by using a suitable smbd interlude script (would also be needed for nmbd, ....) Thsi is similar to bug #8413 and bug #9046 (but the solution can't be to install anything).
IMPORTANT UPDATE!!! The issue is slightly different to that originally stated. It appears that the test *do* set LD_LIBRARY_PATH (or achieve that end some other way). The actual problem is that the RPATH setting in the binaries *cannot be overridden* by LD_LIBRARY_PATH! Indeed, the ld.so manpage on Linux says that is is deprecated (in favour or RUNPATH), presumably as a result of this. But gcc sets RPATH, not RUNPATH, so you are stuffed. If you already have an earlier installation of Samba on your build system in the place where you wish to install the newer version (not an unreasonable state of affairs) then you cannot test the new version, as it will always use the libraries from the old one. So, had it not been for the missing symbol I might have ended up running tests against old samba libraries with no indication of that fact.
FYI: seems you need to use: --enable-new-dtags in gcc/ld in order to get RUNPATH set (and hence get an LD_LIBRARY_PATH overridable setting). http://en.wikipedia.org/wiki/Rpath#The_role_of_GNU_ld
eu-readelf -a /usr/sbin/smbd | grep RPATH gives back nothing here (SerNet RPMs on SUSE) and actually we remove all rpath flags on standard paths in the samba 3.x build system that might come in via krb5-config etc. since a long time. So the rpath you see in your binaries, where do they come from? On a default installations like those you will find in most distribution RPMs you will not see that issue or your distributor might have placed an rpath there for whatever reason. In any case we will not make a change like RPATH->RUNPATH in the stable verions trees anyhow. If you test master (4.0) with the waf build system and you see issues there then we could discuss to change things there. Samba 4 actually *does* use rpath, so testing that would be very welcome!
This is my own build (if I were using RPMs I wouldn't be running the test suite). Configured by: ./configure \ --enable-socket-wrapper \ --enable-nss-wrapper \ --disable-cups \ --prefix=/local/samba (The two enables are needed to run the tests, according to my notes). It seems odd (to me) that on a system with dynamic libraries you would build static versions of daemons. However, that's your choice. It doesn't alter trhe fact that building a (default) shared version with a different version already in the configured destination means that you can't run the testes,.
*** This bug has been marked as a duplicate of bug 9046 ***
This is NOT a duplicate of bug 9046. This is about the fact that you CANNOT RUN THE TESTS WHEN YOU BUILD SAMBA if you already have a different version of Samba installed in the installation location because the test runs will use the installed libraries, not the just-built ones. But it seems that I cannot re-open this ticket.