[PATCH] Shared samba build
David.Collier-Brown at Sun.COM
Mon Nov 14 14:03:53 GMT 2005
Best practice for applications in my organization is to have
at least one .so for common code, with the option to split it
up if the components need to change asynchronously.
Large numbers of separate shared objects require you to
have a way of tracking version skew, lest you have Windows-like
"dll hell", so it's used only when you need to enforce
separation of concerns by technical means. This is usually
when different teams are working on different libraries,
and need to allow for asynchronous update.
The Multics approach was to version-number each
interface (actually each struct) and let the linker
find the right one.
Solaris does an elegant subset of this by
labeling each interface with the version of
the **standard** which adds it.
froggy> pvs -s -v /usr/lib/libthread.so.1 | more
libc.so.1 (SUNW_1.21.2, SUNWprivate_1.1);
means that thr_main was added in the posix-era 2.3
version, revision b.
Without something like that, the manual bookkeeping gets
way to hard, and you end up shipping every dll your application
needs. And you know what this does (;-))
Luke Mewburn wrote:
> On Wed, Oct 26, 2005 at 02:17:08PM +0200, Jelmer Vernooij wrote:
> | Rather then linking everything into one big library, I think we should
> | clearly keep all subsystems seperate. Otherwise, we might end up with
> | the dependency hell we had (have?) in Samba3, with libbigballofmud and
> | the like.
> What exactly is the problem with having one large library
> that all of the Samba applications are linked against?
> A while ago I was amused to find that Samba3 has manually
> maintained lists of object dependencies for each program.
> This means that binaries are bigger than they need to be
> because the linker can't exclude unnecessary object files
> from the list.
> If a library (static libsamba3.a or dynamic libsamba3.so)
> was used instead, this would mean that the linker could select
> only the object files from the library that were actually necessary.
> Here's some numbers I posted in November 2004:
> all progs nmbd+smbd
> --------- ---------
> default build: 16770 KB 2880 KB
> my build, libsamba.a 11870 KB 2656 KB
> my build, libsamba.so 3438 KB 2780 KB (includes libsamba.so)
> Notice the size difference even between the first two entries
> (both static linking the samba-specific objects)
David Collier-Brown, | Always do right. This will gratify
Sun Microsystems, Toronto | some people and astonish the rest
davecb at canada.sun.com | -- Mark Twain
(416) 263-5733 (x65733) |
More information about the samba-technical