waf: Add possibility to build with system libwbclient/libsmbclient
Andreas Schneider
asn at cryptomilk.org
Wed Apr 18 05:26:53 MDT 2012
On Wednesday 18 April 2012 11:06:35 Andreas Schneider wrote:
> On Wednesday 18 April 2012 10:37:00 Andreas Schneider wrote:
> > On Wednesday 18 April 2012 18:08:13 you wrote:
> > > Andreas,
> >
> > Andrew,
> >
> > > Is there any chance you could give me that chance? My work pattern
> > > gives me great flexibility for review, and in most cases it would be
> > > just seeing them by e-mail over the course of my working day would work.
> > > It shouldn't put you too far behind, and give me a good chance to
> > > provide feedback.
> >
> > that's why I contacted you yesterday. I thought you are more or less fine
> > cause you didn't say I should wait and you want to disuss this today.
> > Sorry
> > if you did and I didn't recognize it.
> >
> > > The libwbclient build is a bit interesting it seems, as we have not had
> > > a proper version before. However, Samba4-s3fs strictly depends on the
> > > version 0.8 in master (for IDMAP_BOTH support, I may need to bump the
> > > version to reflect my changes). That is, it won't work with just any
> > > 'version 0' libwbclient.
> > >
> > > For my part, I'll update the version number in the libwbclient header,
> > > but the goal Simo shared with me of using the libwbclient from 3.6
> > > simply won't work.
> > >
> > > On libsmbclient, I wonder if we can find a less intrusive solution to
> > > your concerns. I understand that you want to be able to build packages
> > > against master's libsmbclient, but then have the user install the 3.6
> > > libsmbclient, and not have the linking fail due to the upgrade to
> > > version symbols. Is that the issue, or have I misunderstood it? It
> > > seems a fairly niche use case, but perhaps I don't fully understand the
> > > combinations you propose to support.
> >
> > KDE, Gnome and other components link against libsmbclient and libwbclient.
> > This is for smb:// support or pam_winbind/winbind support in the login
> > managers.
> >
> > Samba4 introduced symbol versioning, which is a good thing but as Samba 3
> > with autoconf didn't have it and all these other components link against
> > it. I can't simply replace them. Adding symbolversioning is a major change
> > and we should probably increase the so version number for that.
> >
> > Alexander and I have tried to solve this issue in serveral ways but this
> > is
> > the only way which is working.
> >
> > > (I realise how this could have been a bigger issue before the dependency
> > > was trimmed down to just smbget and our torture tools)
> > >
> > > If the symbol versions are such a great issue, would it not be simpler
> > > to just turn symbol versions back off? I only added them recently, they
> > > can be (optionally) disabled if they cause that much trouble. For my
> > > part, I'm concerned about how many additional options we both want to
> > > support and test in the long term, where the use case is so far only
> > > defined as transitional packaging need for Red Hat.
> >
> > I think that symbol versioning is good and we shouldn't turn it off, but
> > maybe it is needed for libsmbclient and libwbclient.
>
> I've read drepper his dso paper again and looked at what I do in libssh. If
> you remove the symbol name from the vscript for libsmbclient and libwbclient
> it should work.
>
> smbc_init_context != smbc_init_context@@SMBCLIENT_0.1.0
>
> So if you remove SMBCLIENT_0.1.0 from the vscript it should work.
I think we have a serious problem here. Lets take smblcient as an example here
and how it is some.
Assume Samba4 has been released and we have a security problem in libsmbclient
and fix it and release it. The version was 0.1.0 and it will be 0.1.1.
We will end up with a vscript which only exports version SMBCLIENT_0.1.1 and
everything which links against version 0.1.0 will not work anymore cause the
symbols are not there.
It will look for smbc_init_context@@SMBCLIENT_0.1.0 and will not find it. What
we have now is smbc_init_context@@SMBCLIENT_0.1.1. Cause you don't export the
symbols from the previous version.
I think there shouldn't be any version information in the vscript at all. I
don't think we plan to break the API and have a function which different
prototypes and symbol versioning support. We really don't want to do that
cause it is a pain.
-- andreas
--
Andreas Schneider GPG-ID: F33E3FC6
www.cryptomilk.org asn at cryptomilk.org
More information about the samba-technical
mailing list