Issues in Compiling Rhythmbox under Slackware-14-current
With the upgrade of Samba to the 4.0 series in Slackware-14-Current, Rhythmbox
will no longer configure successfully complaining that gcc cannot compile
programs (!) Further digging reveals a linking error with libtdb: there is a
/usr/lib/libtdb.so.1, a /usr/lib/libtdb.so.1.2.11, but no /usr/lib/libtdb.so.
Further digging reveals there is no /usr/include/tdb.h, necessary to compile
against libtdb, necessary for Rhythmbox to build successfully.
With the Samba 4.0 series, there were two major structural introductions: the
use of waf (yet another 'high-level-build-framework'), and the concept of
'private' vs 'public' libraries. Private libraries do not get their include
files 'published', and the highest level of symbolic linking (the .so -> .so.n)
is not performed.
There are two workarounds (so far) for this issue: one is to build libtdb as a
completely separate standalone library. Some distributions do this, and the
Samba website (and the codebase) has instructions for doing this. I suspect
this would complicate the samba-build process un-necessarily.
Another much simpler, albeit hackier solution is to force the Samba build to
build the library as a public library.
In waf, the configuration stuff is managed through a python script: 'wscript'
at every object level. The wscript in lib/tdb contains a setting which forces
the build of libtdb as private unless it's being built as a standalone which
would introduce other configuration complications.
A simple sed in the SlackBuild suffices to generate a public library:
sed -i -e "s/private_library = True/private_library = False/" lib/tdb/wscript
after the configuration step, but before the build step does the trick. This
could also be done as a patch directly to lib/tdb/wscript but hardly seems
worth the effort.
However, I found that even when I did this, the tdb.h file shows up, but
unfortunately under usr/include/samba-4.0. There is probably a slick waf
trick for changing that, but I just don't know the system well enough, so
I added a simple copy:
cp $PKG/usr/include/samba-4.0/tdb.h $PKG/usr/include
to the SlackBuild after the 'make install' step. I suspect a copy is safer
than a move, but I don't know.
There are other headers in the 'private' library that before were public
including: talloc.h, netapi.h, smb_share_modes.h, wbc_async.h, wbclient.h,
libsmbclient.h, but so far libtdb is the only one I've seen reused in
Here's the differences to the SlackBuild in patch form:
--- samba.SlackBuild.orig 2013-06-05 00:53:41.000000000 -0700
+++ samba.SlackBuild 2013-06-10 12:26:09.515892072 -0700
@@ -125,6 +125,10 @@ CFLAGS="$SLKCFLAGS" \
+# need to force libtdb to be built as a public library, not private
+# (should this be a patch?)
+sed -i -e "s/private_library = True/private_library = False/" lib/tdb/wscript
# -j options don't seem to work...
@@ -142,6 +146,11 @@ chmod 1777 $PKG/var/spool/samba
make install DESTDIR=$PKG || exit 1
+# make a copy of the tdp include file into "public" include space
+# (should the same be done for talloc, netapi, etc?)
+# (should the 4.0 be derived from the $VERSION?)
+cp $PKG/usr/include/samba-4.0/tdb.h $PKG/usr/include
# Install the smbprint script:
install -m0744 packaging/printing/smbprint $PKG/usr/bin/smbprint
It would be great if someone could check this out, or at least let me know how
I'm screwing it up, and even better, if there's a cleaner, simpler way.