[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.
Volker
--
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