The wxWidgets library set can be used to write multi-threading programs that do not use any sort of graphics at all, however current wxGTK package is such that one has to load also tons of graphics application libraries in order to satisfy install requirements. Things would improve, is there was wxbase package carrying self-standing base libraries without any external pre-load requirements (aside of glibc). This matters somewhat to embedded target builders, who possibly have only serial console on the device, and thus the entire X is unnecessary package.
Thanks for the suggestion, but this can't be done trivially, because: $ ldd /usr/lib/libwx_baseu-2.8.so.0 linux-gate.so.1 => (0x00110000) libz.so.1 => /lib/libz.so.1 (0x00270000) libdl.so.2 => /lib/libdl.so.2 (0x00283000) libgstreamer-0.10.so.0 => /usr/lib/libgstreamer-0.10.so.0 (0x00288000) libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0x00334000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00338000) libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0x0046c000) libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0x004a2000) libgthread-2.0.so.0 => /lib/libgthread-2.0.so.0 (0x004fb000) librt.so.1 => /lib/librt.so.1 (0x00500000) libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0x00509000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00549000) libgstinterfaces-0.10.so.0 => /usr/lib/libgstinterfaces-0.10.so.0 (0x00612000) libm.so.6 => /lib/libm.so.6 (0x0061d000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00646000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0072f000) libpthread.so.0 => /lib/libpthread.so.0 (0x0073b000) libc.so.6 => /lib/libc.so.6 (0x00754000) /lib/ld-linux.so.2 (0xb7ef7000)
Comparing application compiled with "just wxbase library" vs. whole devault "wx-config --libs" -bundle: rpm -qf `ldd ./aprsg |awk '{print $3}'`|sort|uniq GConf2-2.19.1-3.fc8.x86_64 glib2-2.14.0-1.fc8.x86_64 glibc-2.6.90-15.x86_64 gstreamer-0.10.14-3.fc8.x86_64 gstreamer-plugins-base-0.10.14-5.fc8.x86_64 libgcc-4.1.2-26.x86_64 libstdc++-4.1.2-26.x86_64 libxml2-2.6.30-1.x86_64 ORBit2-2.14.7-6.fc8.x86_64 wxGTK-2.8.4-6.fc8.x86_64 zlib-1.2.3-14.fc8.x86_64 ps axfu|grep aprsg|... 23766 2.5 0.1 206252 3596 pts/0 Sl 13:44 0:01 ./aprsg The process size when all GTK and X libraries are included: 23886 0.7 0.3 222180 10308 pts/0 S 13:48 0:00 ./aprsg Ok, the difference is not all that big.. mere factor 3 :-) Then LDD report: linux-vdso.so.1 => (0x00007fffb47fd000) libwx_gtk2u_aui-2.8.so.0 => /usr/lib64/libwx_gtk2u_aui-2.8.so.0 (0x00002aaaaacc7000) libwx_gtk2u_xrc-2.8.so.0 => /usr/lib64/libwx_gtk2u_xrc-2.8.so.0 (0x00002aaaaaf20000) libwx_gtk2u_qa-2.8.so.0 => /usr/lib64/libwx_gtk2u_qa-2.8.so.0 (0x00002aaaab1be000) libwx_gtk2u_html-2.8.so.0 => /usr/lib64/libwx_gtk2u_html-2.8.so.0 (0x00002aaaab3e3000) libwx_gtk2u_adv-2.8.so.0 => /usr/lib64/libwx_gtk2u_adv-2.8.so.0 (0x00002aaaab698000) libwx_gtk2u_core-2.8.so.0 => /usr/lib64/libwx_gtk2u_core-2.8.so.0 (0x00002aaaab980000) libwx_baseu_xml-2.8.so.0 => /usr/lib64/libwx_baseu_xml-2.8.so.0 (0x00002aaaabfb7000) libwx_baseu_net-2.8.so.0 => /usr/lib64/libwx_baseu_net-2.8.so.0 (0x00002aaaac1c1000) libwx_baseu-2.8.so.0 => /usr/lib64/libwx_baseu-2.8.so.0 (0x00002aaaac3f3000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002aaaac760000) libm.so.6 => /lib64/libm.so.6 (0x00002aaaaca60000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002aaaacce3000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaacef2000) libc.so.6 => /lib64/libc.so.6 (0x00002aaaad10d000) libz.so.1 => /lib64/libz.so.1 (0x000000350b400000) libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaad463000) libgstreamer-0.10.so.0 => /usr/lib64/libgstreamer-0.10.so.0 (0x0000003518200000) libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x0000003511400000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0000003516200000) libgconf-2.so.4 => /usr/lib64/libgconf-2.so.4 (0x000000351a600000) libORBit-2.so.0 => /usr/lib64/libORBit-2.so.0 (0x0000003519a00000) libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x0000003512000000) librt.so.1 => /lib64/librt.so.1 (0x00002aaaad669000) libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x0000003510c00000) libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x000000350e800000) libgstinterfaces-0.10.so.0 => /usr/lib64/libgstinterfaces-0.10.so.0 (0x000000351b200000) libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x0000003513c00000) libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x0000003514200000) libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x0000003513800000) libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x0000003512400000) libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x0000003512800000) libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x000000350f000000) libSM.so.6 => /usr/lib64/libSM.so.6 (0x000000350d800000) libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x000000350d000000) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x0000003511800000) libtiff.so.3 => /usr/lib64/libtiff.so.3 (0x000000351f200000) libSDL-1.2.so.0 => /usr/lib64/libSDL-1.2.so.0 (0x0000003515200000) libexpat.so.1 => /lib64/libexpat.so.1 (0x000000350e000000) /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000) libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x0000003513000000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x000000350bc00000) libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x000000350f400000) libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x0000003512c00000) libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x000000350e400000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x000000350cc00000) libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x000000350ec00000) libXi.so.6 => /usr/lib64/libXi.so.6 (0x000000350f800000) libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x0000003510000000) libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x000000350fc00000) libICE.so.6 => /usr/lib64/libICE.so.6 (0x000000350d400000) libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x0000003513400000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x000000350dc00000) libxcb-xlib.so.0 => /usr/lib64/libxcb-xlib.so.0 (0x000000350c000000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x000000350b800000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x000000350c800000) libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x000000350c400000) I would love to shrink it even more -- indeed I am rewriting some tools just because even "bare minimum" wxWidget set is too heavy.. Note: I am thinking of Linux capable embedded targets, not some watch processor.
Ahh... this one I intended for the second list: atk-1.19.6-3.fc8.x86_64 cairo-1.4.10-2.fc8.x86_64 expat-2.0.1-2.x86_64 fontconfig-2.4.2-5.fc8.x86_64 freetype-2.3.5-3.fc8.x86_64 GConf2-2.19.1-3.fc8.x86_64 glib2-2.14.0-1.fc8.x86_64 glibc-2.6.90-15.x86_64 gstreamer-0.10.14-3.fc8.x86_64 gstreamer-plugins-base-0.10.14-5.fc8.x86_64 gtk2-2.11.6-7.fc8.x86_64 libgcc-4.1.2-26.x86_64 libICE-1.0.3-3.fc8.x86_64 libjpeg-6b-39.fc8.x86_64 libpng-1.2.16-3.fc8.x86_64 libSM-1.0.2-2.fc8.x86_64 libstdc++-4.1.2-26.x86_64 libtiff-3.8.2-9.fc8.x86_64 libX11-1.1.2-2.fc8.x86_64 libXau-1.0.3-3.fc8.x86_64 libxcb-1.0-3.fc8.x86_64 libXcursor-1.1.8-3.fc8.x86_64 libXdmcp-1.0.2-4.fc8.x86_64 libXext-1.0.1-4.fc8.x86_64 libXfixes-4.0.3-2.fc8.x86_64 libXi-1.1.1-2.fc8.x86_64 libXinerama-1.0.2-3.fc8.x86_64 libxml2-2.6.30-1.x86_64 libXrandr-1.2.0-5.fc8.x86_64 libXrender-0.9.3-1.fc8.x86_64 ORBit2-2.14.7-6.fc8.x86_64 pango-1.18.0-1.fc8.x86_64 SDL-1.2.12-2.fc8.x86_64 wxGTK-2.8.4-6.fc8.x86_64 zlib-1.2.3-14.fc8.x86_64
Yeah, but the wxbase lib itself is also linked against all that stuff. I'm not sure it can be built for use with wxGTK without doing that.
Nevertheless, having a wxbase rpm with wx_baseu, wx_net, and wx_xml, the current external library requirements for my software shrinks by factor 3.. That includes things like SDL, pango, libX*, libSM, gtk2, libICE, expat, atk, fontconfig, freetype.. at least. Anything that has needs for graphics related bits. For my workstation I don't much care if I have to load a GB more or less of package bits, but for an embedded target the size of flash device is limited. At the same time, copying bits that are really needed to satisfy linking is an option, or making custom library versions, but I would like to spend those hours at the application rather than environment issues.
We could probably construct a package like that, although it'd be ideal if there weren't any code duplication. But it wouldn't really be part of wxGTK -- it'd be a separate source RPM. I wouldn't block anyone who wants to create such a thing, but I don't have time to add new packages to my responsibilities right now.
Why can't you make wxbase package and smaller wxGTK (excluding wxbase stuff), which would depend on wxbase? AFAIK Debian does this. And I see wxGTK.spec in wx does it.
Nerujus -- what would be the advantage? wxbase links against all of the libraries that cause all of the dependencies. (As noted in comment #1 and comment #4.) I'm not sure that a wxbase package built without that linking would be useful for wxGTK. I'll investigate what the upstream package does, though.
Let's see if wxbase links against all of the libraries that cause all of the dependencies: ldd /usr/lib/libwx_baseu-2.8.so.0|sort|awk '{print $1}' >base ldd /usr/lib/libwx_gtk2u_core-2.8.so.0|sort|awk '{print $1}' >gtk diff -u base gtk --- base 2007-11-20 21:54:05.000000000 +0200 +++ gtk 2007-11-20 21:54:14.000000000 +0200 @@ -1,19 +1,48 @@ +libatk-1.0.so.0 +libcairo.so.2 libc.so.6 libdl.so.2 +libexpat.so.1 +libfontconfig.so.1 +libfreetype.so.6 libgcc_s.so.1 libgconf-2.so.4 +libgdk_pixbuf-2.0.so.0 +libgdk-x11-2.0.so.0 libglib-2.0.so.0 libgmodule-2.0.so.0 libgobject-2.0.so.0 libgstinterfaces-0.10.so.0 libgstreamer-0.10.so.0 libgthread-2.0.so.0 +libgtk-x11-2.0.so.0 +libICE.so.6 +libjpeg.so.62 /lib/ld-linux.so.2 libm.so.6 libORBit-2.so.0 +libpango-1.0.so.0 +libpangocairo-1.0.so.0 +libpangoft2-1.0.so.0 +libpng12.so.0 libpthread.so.0 librt.so.1 +libSM.so.6 libstdc++.so.6 +libtiff.so.3 +libwx_baseu-2.8.so.0 +libX11.so.6 +libXau.so.6 +libxcb.so.1 +libxcb-xlib.so.0 +libXcursor.so.1 +libXdmcp.so.6 +libXext.so.6 +libXfixes.so.3 +libXinerama.so.1 +libXi.so.6 libxml2.so.2 +libXrandr.so.2 +libXrender.so.1 libz.so.1 linux-gate.so.1 Both wabase and wxgtk have these most interesting deps: libglib-2.0.so.0 libgmodule-2.0.so.0 libgobject-2.0.so.0 libgstinterfaces-0.10.so.0 libgstreamer-0.10.so.0 libgthread-2.0.so.0 libORBit-2.so.0 These are from glib2, gstreamer, gstreamer-plugins-base and ORBit2. rpm -q --requires ORBit2: (glib stuff) rpm -q --requires gstreamer: gstreamer-tools >= 0.10.14 (glib, xml stuff) rpm -q --requires gstreamer-tools: (glib) rpm -q --requires gstreamer-plugins-base: (alsa, glib, libX11, libXext, libXv, libgnomevfs, libpango) So the biggest problem is gstreamer-plugins-base. Either gstreamer package should not require gstreamer-plugins-base or wxbase should not require gstreamer ( I'll ask in wx list about it).
It's indeed completely unnecessary to link wxBase with gstreamer (thanks for noticing this Nerijus!) and it has been corrected in svn and will be fixed in tthe next release (2.8.8). Please see http://svn.wxwidgets.org/viewvc/wx?view=rev&revision=50114 if you want to apply the fix to the currently packaged version, it is trivial. So the answer the comment #8 is that wxBase package should definitely be used as dependency of wxGTK, the presence of gstreamer libraries was nothing but a bug.
Thanks everyone. I'll work on an updated package.
> http://svn.wxwidgets.org/viewvc/wx?view=rev&revision=50114 if you want to Second part of the fix is here (only wxMedia library needs GStreamer, the others don't need it): http://svn.wxwidgets.org/viewvc/wx?view=rev&revision=50120
Based on the date this bug was created, it appears to have been reported during the development of Fedora 8. In order to refocus our efforts as a project we are changing the version of this bug to '8'. If this bug still exists in rawhide, please change the version back to rawhide. (If you're unable to change the bug's version, add a comment to the bug and someone will change it for you.) Thanks for your help and we apologize for the interruption. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping