libraries and the build system

Luke Mewburn luke at mewburn.net
Thu Nov 18 07:06:31 GMT 2004


On Thu, Nov 18, 2004 at 09:51:11AM +1100, tridge at samba.org wrote:
  | Andreas,
  | 
  |  > So do static libraries. What if there is a problem with the library
  |  > which requires rebuilding all applications which used it statically?
  |  > Is everybody prepared to rebuild KDE and GNOME components? They use
  |  > libsmbclient (shared) today.
  |  > 
  |  > If that's not what this is about, sorry, just ignore this email.
  | 
  | for external (non-samba) apps on modern platforms shared libs do
  | indeed make sense for exactly that reason.
  | 
  | but we can't take them on lightly. We need a plan (and volunteers for
  | the effort) to create libs that won't be more of a curse than a
  | benefit.
  | 
  | for internal samba use their benefits are much more dubious.

Think ``Embedded platforms'' with minimal disk space...

As I've discussed (privately) with Tridge and a few others, converting
the samba3 build to using a large libsamba.a or libsamba.so has
beneficial disk space savings.

My original numbers, based on a custom build infrastructure,  were:

                                all progs       nmbd+smbd
                                ---------       ---------
        "native" build:         16770 KB        2880 KB
        our build, libsamba.a   11870 KB        2656 KB
        our build, libsamba.so  3438 KB         2780 KB (includes libsamba.so)

As we can see, even using libsamba.a saves space, because it lets the
linker do the job of trimming out the unnecessary stuff.
Currently samba builds up lists of .o files from a nested mess
of make(1) variables and passes that to the linker, which links
every given .o file into the target application, even if that
application doesn't need it.

Once the work is performed for libsamba.a (e.g, for all samba
builds), then it's trivial for third party packagers to build
a libsamba.so instead (in their private builds) and link against
that.  I did a proof of concept that converted most of samba 3.0.6
to the libsamba.a approach.

I think migrating to libsamba.a is a worthwhile thing, as it
lets the linker automate the job of minimizing the on-disk
size of samba by not linking in crap we don't need, instead of
relying upon the developer to select the "right" list of
FOO_OBJ variables in the Makefile.  It may also speed up building
& linking.

Cheers,
Luke.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20041118/22366345/attachment.bin


More information about the samba-technical mailing list