Running master/Samba3 fails because of system talloc

[simo]

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.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>