[PATCH] Just another round of random cleanups

Volker Lendecke Volker.Lendecke at SerNet.DE
Thu Sep 18 06:31:20 MDT 2014

On Thu, Sep 18, 2014 at 10:19:02PM +1000, Martin Schwenke wrote:
> On Thu, 18 Sep 2014 13:28:44 +0200, Volker Lendecke
> <Volker.Lendecke at SerNet.DE> wrote:
> > On Thu, Sep 18, 2014 at 07:51:13PM +1000, Martin Schwenke wrote:
> > > I'm happy to do convert subsystems into private libraries... but I'd
> > 
> > Not a good idea. Every library that we link in does have a
> > cost in every process. I think for production use, i.e.
> > without --developer) we need the libbigballofmud.so again.
> > For developer, fine, every C file can get its own .so, but
> > not for what we ship.
> I'm not sure what you're suggesting.
> 1. Change the problem dependencies into private libraries by default so
>    that autobuild passes.  Then have any packaging specs build-in those
>    libraries and put up with the duplicate symbols across libraries.
>    If the duplicate symbols are actually OK, then why don't we allow it
>    in autobuild?  I guess they are not OK.
>    It really does seem stupid to have to depend on samba-util when all
>    you want is samba-debug.
>    I actually have the same patch as you for tdb_wrap in one of my
>    branches because I wanted to do the same dependency cleanup.
> I guess that using a private library is how we get around everything
> needing replace.
> I would almost argue that samba-debug should be treated the same way
> except that it does actually depend on a few things subsystems from
> lib/util.  I guessing that if we make samba-debug a private library
> then we end up with a similar problem for things like time-basic and
> close-low-fd.  It's turtles all the way down...

Maybe we will eventually end up with a shared library per C file. If
that's the way to go, so be it.


SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de

More information about the samba-technical mailing list