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
The problem is in trying to building talloc as a .so when a different
version is found on the system. Not going to work.
Samba Team GPL Compliance Officer <[email protected]>
Principal Software Engineer at Red Hat, Inc. <[email protected]>