After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 561187 - Links statically a lot of files in each backend
Links statically a lot of files in each backend
Status: RESOLVED FIXED
Product: gvfs
Classification: Core
Component: build
1.2.x
Other Linux
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2008-11-17 11:38 UTC by Josselin Mouette
Modified: 2013-12-12 16:38 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
Convert libdaemon to a shared library (1.43 KB, patch)
2013-10-28 19:53 UTC, Ross Lagerwall
accepted-commit_now Details | Review
Convert libdaemon to a private shared library (1.51 KB, patch)
2013-12-05 18:13 UTC, Ross Lagerwall
accepted-commit_now Details | Review
Convert libgvfscommon to a private shared library (1.06 KB, patch)
2013-12-05 18:15 UTC, Ross Lagerwall
accepted-commit_now Details | Review

Description Josselin Mouette 2008-11-17 11:38:07 UTC
Currently, all common functions to the different gvfs backends are built as libdaemon.la and linked statically into each backend. Because of that, each backend is > 100KB. Linking them dynamically would reduce the binary package size quite a bit, and would save users memory by using shared segments when several backends are in use.

If the API for these functions is not meant to be stable, it is possible to put it in a shared library nevertheless; my favorite way to do this is to call libtool -release to enforce library soname changes.
Comment 1 Alexander Larsson 2009-03-09 14:13:47 UTC
Its now shared.
Comment 2 Josselin Mouette 2009-04-29 18:38:34 UTC
I’ve just built gvfs 1.2.2, and the common functions are still linked statically. The smallest backend is 732K on amd64, so that makes 13 MB for all backends. This makes gvfs-backends one of the biggest binary packages of the GNOME suite.
Comment 3 Josselin Mouette 2009-04-29 19:13:13 UTC
Sorry, I looked at the unstripped binaries. Stripped are about 130K, so that’s the same as with 1.0. The bug is not fixed, but it has not gotten worse :)
Comment 4 Ross Lagerwall 2013-10-28 19:53:16 UTC
Created attachment 258339 [details] [review]
Convert libdaemon to a shared library

Convert libdaemon to be a shared library called libgvfsdaemon, much like
libgvfscommon.  It has the benefit of reducing the binary size of each
daemon by between 100 and 200KB and reduces the memory footprint if
using several backends at the same time.
Comment 5 Ondrej Holy 2013-12-05 17:07:12 UTC
Review of attachment 258339 [details] [review]:

Looks good to me, hopefully this doesn't break anything...
Comment 6 Ondrej Holy 2013-12-05 17:12:28 UTC
Review of attachment 258339 [details] [review]:

::: daemon/Makefile.am
@@ +200,3 @@
         $(NULL)
 
+libgvfsdaemon_la_LDFLAGS = -no-undefined

Would be nice to add comment same as in common/Makefile.am:
# needed by cygwin (see bug #564003)
Comment 7 Ross Lagerwall 2013-12-05 18:13:10 UTC
Thanks. I see now that Debian has a similar patch [1]. I think we should change lib_LTLIBRARIES to pkglib_LTLIBRARIES for libgvfs{daemon,common} and add -avoid-version since they are private libraries? (as done with libgedit-private in [2])


[1] http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gvfs/debian/patches/05_shared_libdaemon.patch?revision=37904&view=markup
[2] https://git.gnome.org/browse/gedit/tree/gedit/Makefile.am
Comment 8 Ross Lagerwall 2013-12-05 18:13:53 UTC
Created attachment 263618 [details] [review]
Convert libdaemon to a private shared library
Comment 9 Ross Lagerwall 2013-12-05 18:15:09 UTC
Created attachment 263619 [details] [review]
Convert libgvfscommon to a private shared library
Comment 10 Ondrej Holy 2013-12-12 16:18:05 UTC
Review of attachment 263618 [details] [review]:

Looks good!
Comment 11 Ondrej Holy 2013-12-12 16:18:07 UTC
Review of attachment 263618 [details] [review]:

Looks good!
Comment 12 Ondrej Holy 2013-12-12 16:18:35 UTC
Review of attachment 263619 [details] [review]:

Looks good!
Comment 13 Ross Lagerwall 2013-12-12 16:38:43 UTC
Pushed to master as 9ec8f2e84e97831d1ce97d8daa7b590349e08415. Thanks!