> On Tue, 2009-03-24 at 13:51 +0100, Jelmer Vernooij wrote:
>> Andrew Bartlett wrote:
>>> I've just built Samba3 from master, and have found that, because I have
>>> libtalloc on my system, it prefers to link against this (and fail to
>>> run), than to use the copy Samba3 built.
>>> bin/smbclient: symbol lookup error: bin/smbclient: undefined symbol:
>>> This is because I have: libtalloc-1.2.0 installed on my Fedora 10
>>> I realise this is because I've not yet installed Samba3 (I am running
>>> from the checkout), and even if I had installed it, I would not have yet
>>> updated my ld.so.conf manually to point to Samba3's directory, or set
>>> LD_LIBRARY_PATH (annoying, but possible).
>>> However, this isn't the whole problem - what would have happened if we
>>> had changed the ABI more abruptly: Not just adding a new symbol, but
>>> changing a prototype? As far as I can see, the only indication would
>>> have been a segfault, not a linker failure.
>>> Also, if I did update my ld.so.conf, how should the rest of the system
>>> react (I presume 'something' stops the newer version being a problem for
>>> the other OS applications that required libtalloc in the first place)?
>>> Should symbol versions play some role here?
>>> Samba4 currently builds and runs fine for me, because when it fails to
>>> link against system libraries, a static copy is used. Why (in all
>>> seriousness, I would like to understand the reason) does Samba3 not use
>>> this approach?
>>> Could Samba3 adopt the Samba4 approach, which has worked pretty well for
>>> quite a while now? Alternately, could this approach be used at least
>>> when the install directory is not in ld.so.conf?
>>> Finally, I do think we need to agree on a common strategy for these
>>> situations for both trees in the master branch. We can't continue to
>>> merge development efforts while having two very different expected
>>> behaviours here.
>>> As long as all the problems are addressed, I'm not particularly fixed on
>>> what scheme is used, as long as it is consistent across all our
>>> development efforts, and is consistent with producing and being
>>> compatible with what final packaged systems require.
>> I had this issue a week or so ago as well, and it turned out to be
>> caused by the fact that -L/usr/lib ends up in my LDFLAGS, thus causing
>> the system talloc to be found before the one in bin/, even if configure
>> has decided not to use the system talloc. Are you perhaps hitting a
>> similar issue?
>> fwiw, configure will already only use the system talloc if it is 1.3 or
> The problem is in trying to building talloc as a .so when a different
> version is found on the system. Not going to work.
It'll work fine as long as LD_LIBRARY_PATH is set, so should be
sufficient for e.g. "make test" which sets it for you or running the
binaries as long as you have LD_LIBRARY_PATH set manually.