Running master/Samba3 fails because of system talloc

[Jelmer Vernooij]

simo wrote:
> 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
>>> 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.
>>     
>
> 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.

Cheers,

Jelmer