Running master/Samba3 fails because of system talloc

Andrew Bartlett abartlet at samba.org
Tue Mar 24 09:57:29 GMT 2009


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
bin/smbclient: symbol lookup error: bin/smbclient: undefined symbol:
_talloc_get_type_abort

This is because I have: libtalloc-1.2.0 installed on my Fedora 10
system.

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.

Thanks,

Andrew Bartlett
-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20090324/a6e0b77b/attachment.bin


More information about the samba-technical mailing list