[PATCH] Shared samba build

[David Collier-Brown]

  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. 

[Off topic]
  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. 
  For example,
froggy> pvs -s -v /usr/lib/libthread.so.1 | more
	libc.so.1 (SUNW_1.21.2, SUNWprivate_1.1);
	libdl.so.1 (SUNWprivate_1.1);
...
	SISCD_2.3b:
		SISCD_2.3b;
		thr_stksegment;
		thr_main;
	SISCD_2.3a:
		cond_signal;
		rw_rdlock;
		mutex_unlock;
		sema_trywait;
...

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 (;-))

--dave


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)
> 
> cheers,
> Luke.

-- 
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)   |