Devin Carraway <[EMAIL PROTECTED]> immo vero scripsit:
> Ignoring the irksome ld.so issues for a moment, upstram for this package
> is doing exactly the right thing by putting common functionality out in
> shared libs, even if the only executables sharing them are the ones in
> the package itself. There are 11 executables in this package, of about
> 30k each, plus 3 libs of about 75k each; each executable links against
> two of the libs. Linking the private libs statically would roughly
> triple the size of the package.
I wouldn't really worry about 75k each.
If it's something exceeding 1MB, I would start worrying about them.
Did you measure the overhead of shared libraries vs. linking them
statically ? My local source tells me that making shared libs
has some overhead that is significant enough to make my
code 208k when it builds with shared lib (3 shared libs, and 2
binaries) and 170k static.
Considering that being a shared library apparently reduces the
number of available CPU registers on i386 systems, I wonder where the
advantage lies.
> There are plenty of packages using private subdirs of /usr/lib/ to store
> shared libraries, though most seem to access them directly dlopen().
They are different in that they are plugins.
Some just do dlopen for the sake of it, but there are
applications which are dynamically pluggable.
(like LADSPA).
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
