Running master/Samba3 fails because of system talloc

[Jelmer Vernooij]

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
> 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.
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 
higher.

Cheers,

Jelmer