3 ms·

gedit is pretty complex. libgtksourceview-2.0.so.0 libgconf-2.so.4 liblaunchpad-integration.so.1 libgtk-x11-2.0.so.0 libgdk-x11-2.0.so.0

gedit is pretty complex. libgtksourceview-2.0.so.0 libgconf-2.so.4 liblaunchpad-integration.so.1 libgtk-x11-2.0.so.0 libgdk-x11-2.0.so.0 libatk-1.0.so.0 libgio-2.0.so.0 libgdk_pixbuf-2.0.so.0 libcairo.so.2 libpango-1.0.so.0 libgobject-2.0.so.0 libgmodule-2.0.so.0 libgthread-2.0.so.0 libglib-2.0.so.0 libX11.so.6 libSM.so.6 libm.so.6 libpthread.so.0 libc.so.6 libICE.so.6 libpangocairo-1.0.so.0 libxml2.so.2 libORBit-2.so.0 libdbus-glib-1.so.2 libdbus-1.so.3 librt.so.1 libXcomposite.so.1 libXdamage.so.1 libXfixes.so.3 libpangoft2-1.0.so.0 libfreetype.so.6 libfontconfig.so.1 libXext.so.6 libXrender.so.1 libXinerama.so.1 libXi.so.6 libXrandr.so.2 libXcursor.so.1 libdl.so.2 libpcre.so.3 libresolv.so.2 libz.so.1 libselinux.so.1 libpixman-1.so.0 libdirectfb-1.2.so.0 libfusion-1.2.so.0 libdirect-1.2.so.0 libpng12.so.0 libxcb-render-util.so.0 libxcb-render.so.0 libxcb.so.1 libuuid.so.1 libexpat.so.1 libXau.so.6 libXdmcp.so.6 How would you improve? Outside the duplication of XCB and the libX11 based libraries, it's hard for me to see much that isn't at least justifiable. I understand why the X extension libraries are all broken up. But, in the modern world, it seems likely the same set get loaded time and time again. It would be "simpler" if they were all in one library. gobject/glib/gmodule and friends could get sewn up. Same as gdk/gtk/atk. (Though, why the hell is directfb in there?)

yason 16y ago
Here's a rough logical grouping, based on whatever I might be interested as the "end-developer"—i.e. the guy who just wants to use these libraries and not be concerned too much about how they're internally stacked together. Note that I simply recognize many of these libraries but I'm definitely not an expert on each one, so many of them might belong to some other logical group. YMMV. First, GUI stuff: if I want to make graphical UIs in style of GTK, then I probably want all of these and more. libgtkgui.so: - libatk-1.0.so.0 - libgdk-x11-2.0.so.0 - libgdk_pixbuf-2.0.so.0 - libgtk-x11-2.0.so.0 - libgtksourceview-2.0.so.0 - libpng12.so.0 Font rendering: if I want to render text I'll probably want all of these anyway, preferably facaded over one high-level API. libfonts.so: - libcairo.so.2 - libfontconfig.so.1 - libfreetype.so.6 - libpango-1.0.so.0 - libpangocairo-1.0.so.0 - libpangoft2-1.0.so.0 Basic G-stuff: if I want to use the low-level glib etc. stuff without GTK and other gui stuff, I probably want something like this. libgbase.so: - libORBit-2.so.0 - libgconf-2.so.4 - libgio-2.0.so.0 - libglib-2.0.so.0 - libgmodule-2.0.so.0 - libgobject-2.0.so.0 - libgthread-2.0.so.0 - libuuid.so.1 If I want to do X development, I probably can't avoid dragging most of these with me already, and I'm not particularly interested in which libraries might I possibly need. All I want is X. libx.so: - libICE.so.6 - libSM.so.6 - libX11.so.6 - libXau.so.6 - libXcomposite.so.1 - libXcursor.so.1 - libXdamage.so.1 - libXdmcp.so.6 - libXext.so.6 - libXfixes.so.3 - libXi.so.6 - libXinerama.so.1 - libXrandr.so.2 - libXrender.so.1 - libdirect-1.2.so.0 - libdirectfb-1.2.so.0 - libfusion-1.2.so.0 - libpixman-1.so.0 - libxcb-render-util.so.0 - libxcb-render.so.0 - libxcb.so.1 The very base posix environment: I'll have to link with many of these already so it would be handy to just umbrella them into one base lib. I would also not have to remember if I need libm or libpthreads separately as is the case with slightly different Unix environments these days. libposixish.so: - libc.so.6 - libdl.so.2 - libm.so.6 - libpcre.so.3 - libpthread.so.0 - libresolv.so.2 - librt.so.1 - libselinux.so.1 - libz.so.1 These are surprisingly non-dependent on other libraries so these could be bundled into one small library. I think. libxml.so: - libexpat.so.1 - libxml2.so.2 Not sure if this would be part of my libgtkgui.so or libgbase.so or libposixish.so, or if they would belong to something called libgnome.so, so they're left here as separate libraries. libdbus-1.so.3 libdbus-glib-1.so.2 liblaunchpad-integration.so.1 I'm pretty sure there are niche cases where you would really want to reuse a particular sub-library only, but you could just depend on the big blob anyway. You see, the common parts of the big blob are in use and in memory already as the whole thing is mapped from disk to memory. But if nobody uses a particular sub-library it won't be loaded to actual memory either until someone touches its address space. So, instead of linking with the sublibrary directly, you could just start using it within the big library, and the same process of loading from disk to memory will then automatically happen. Conversely, even if you have a gigantic 100MB libgnome you might just generally end up having only a part of it in memory.

yason 16y ago

Here's a rough logical grouping, based on whatever I might be interested as the "end-developer"—i.e. the guy who just wants to use these libraries and not be concerned too much about how they're internally stacked together. Note that I simply recognize many of these libraries but I'm definitely not an expert on each one, so many of them might belong to some other logical group. YMMV. First, GUI stuff: if I want to make graphical UIs in style of GTK, then I probably want all of these and more. libgtkgui.so: - libatk-1.0.so.0 - libgdk-x11-2.0.so.0 - libgdk_pixbuf-2.0.so.0 - libgtk-x11-2.0.so.0 - libgtksourceview-2.0.so.0 - libpng12.so.0 Font rendering: if I want to render text I'll probably want all of these anyway, preferably facaded over one high-level API. libfonts.so: - libcairo.so.2 - libfontconfig.so.1 - libfreetype.so.6 - libpango-1.0.so.0 - libpangocairo-1.0.so.0 - libpangoft2-1.0.so.0 Basic G-stuff: if I want to use the low-level glib etc. stuff without GTK and other gui stuff, I probably want something like this. libgbase.so: - libORBit-2.so.0 - libgconf-2.so.4 - libgio-2.0.so.0 - libglib-2.0.so.0 - libgmodule-2.0.so.0 - libgobject-2.0.so.0 - libgthread-2.0.so.0 - libuuid.so.1 If I want to do X development, I probably can't avoid dragging most of these with me already, and I'm not particularly interested in which libraries might I possibly need. All I want is X. libx.so: - libICE.so.6 - libSM.so.6 - libX11.so.6 - libXau.so.6 - libXcomposite.so.1 - libXcursor.so.1 - libXdamage.so.1 - libXdmcp.so.6 - libXext.so.6 - libXfixes.so.3 - libXi.so.6 - libXinerama.so.1 - libXrandr.so.2 - libXrender.so.1 - libdirect-1.2.so.0 - libdirectfb-1.2.so.0 - libfusion-1.2.so.0 - libpixman-1.so.0 - libxcb-render-util.so.0 - libxcb-render.so.0 - libxcb.so.1 The very base posix environment: I'll have to link with many of these already so it would be handy to just umbrella them into one base lib. I would also not have to remember if I need libm or libpthreads separately as is the case with slightly different Unix environments these days. libposixish.so: - libc.so.6 - libdl.so.2 - libm.so.6 - libpcre.so.3 - libpthread.so.0 - libresolv.so.2 - librt.so.1 - libselinux.so.1 - libz.so.1 These are surprisingly non-dependent on other libraries so these could be bundled into one small library. I think. libxml.so: - libexpat.so.1 - libxml2.so.2 Not sure if this would be part of my libgtkgui.so or libgbase.so or libposixish.so, or if they would belong to something called libgnome.so, so they're left here as separate libraries. libdbus-1.so.3 libdbus-glib-1.so.2 liblaunchpad-integration.so.1 I'm pretty sure there are niche cases where you would really want to reuse a particular sub-library only, but you could just depend on the big blob anyway. You see, the common parts of the big blob are in use and in memory already as the whole thing is mapped from disk to memory. But if nobody uses a particular sub-library it won't be loaded to actual memory either until someone touches its address space. So, instead of linking with the sublibrary directly, you could just start using it within the big library, and the same process of loading from disk to memory will then automatically happen. Conversely, even if you have a gigantic 100MB libgnome you might just generally end up having only a part of it in memory.