Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d
Hi! zion:~# apt-cache showpkg libsdl-mixer1.2 libsdl-net1.2 libsdl1.2debian-all | grep '^ ' | sort -u | cut -d ',' -f 1 /tmp/sdldeps zion:~# apt-cache showpkg libwxgtk2.4 | grep '^ ' | sort -u | cut -d ',' -f 1 /tmp/wxdeps zion:~# diff -u /tmp/sdldeps /tmp/wxdeps | grep '^ ' scorched3d zion:~# It seems that this conflict only affects scorched3d. Is there a possibility to check for these things on a global level? Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d
On Thu, Mar 24, 2005 at 11:42:48AM +0100, David Schmitt wrote: zion:~# apt-cache showpkg libsdl-mixer1.2 libsdl-net1.2 libsdl1.2debian-all | grep '^ ' | sort -u | cut -d ',' -f 1 /tmp/sdldeps zion:~# apt-cache showpkg libwxgtk2.4 | grep '^ ' | sort -u | cut -d ',' -f 1 /tmp/wxdeps zion:~# diff -u /tmp/sdldeps /tmp/wxdeps | grep '^ ' scorched3d zion:~# It seems that this conflict only affects scorched3d. Yep since nothing else depends on libwxgtk2.4 and libsdl in the same time. Is there a possibility to check for these things on a global level? Thanks David for checking this. I made further checks and here's what I got: [ sid / unstable ] ([EMAIL PROTECTED])~$ldd /usr/lib/libSDL.so libartsc.so.0 = /usr/lib/libartsc.so.0 (0x40103000) libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0 (0x40109000) libgthread-2.0.so.0 = /usr/lib/libgthread-2.0.so.0 (0x4010e000) libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x40113000) libesd.so.0 = /usr/lib/libesd.so.0 (0x40193000) libaudiofile.so.0 = /usr/lib/libaudiofile.so.0 (0x4019b000) libaudio.so.2 = /usr/lib/libaudio.so.2 (0x401bf000) libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x401d4000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x40226000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x402ed000) libvga.so.1 = /usr/lib/libvga.so.1 (0x402fb000) libaa.so.1 = /usr/lib/libaa.so.1 (0x4036) libasound.so.2 = /usr/lib/libasound.so.2 (0x4037c000) libm.so.6 = /lib/libm.so.6 (0x4042f000) libdl.so.2 = /lib/libdl.so.2 (0x40452000) libpthread.so.0 = /lib/libpthread.so.0 (0x40455000) libc.so.6 = /lib/libc.so.6 (0x404a6000) libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x405d9000) libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x405e2000) libncurses.so.5 = /lib/libncurses.so.5 (0x405fa000) libslang.so.1 = /lib/libslang.so.1 (0x40639000) libgpm.so.1 = /usr/lib/libgpm.so.1 (0x406ac000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) ([EMAIL PROTECTED])~$ [ sarge / testing ] ([EMAIL PROTECTED])~$ldd /usr/lib/libSDL.so libm.so.6 = /lib/libm.so.6 (0x400ad000) libdl.so.2 = /lib/libdl.so.2 (0x400cf000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x400d2000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x4019a000) libpthread.so.0 = /lib/libpthread.so.0 (0x401a8000) libc.so.6 = /lib/libc.so.6 (0x401f9000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) ([EMAIL PROTECTED])~$ Any reason for such huge disproportions? That's where we got libglib2.0. Scorched3D built on sarge works fine and doesn't link against libglib2.0. I asked some of mine friends using other distros for pasting me output of `ldd /usr/lib/libSDL.so | wc -l` Here are some stats [ we've got in sid 23 ] slackware current - 11 gentoo - 14 (we know this could vary a lot) Also seems that other distros have wxgtk2.4 linked against libglib2.0 and libsdl doesn't linked against any libglib. This way most other distros have scorched3d linked against libglib2.0, but only because wxgtk2.4 and not libsdl. I'm not sure what to do now. Is it possible to link our wxgtk2.4 against glib2.0? Or unlink libsdl from using libglib? regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d
Le jeudi 24 mars 2005 à 14:37 +0100, Bartosz Fenski aka fEnIo a écrit :
[ sid / unstable ]
([EMAIL PROTECTED])~$ldd /usr/lib/libSDL.so
libartsc.so.0 = /usr/lib/libartsc.so.0 (0x40103000)
libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0 (0x40109000)
libgthread-2.0.so.0 = /usr/lib/libgthread-2.0.so.0 (0x4010e000)
libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x40113000)
libesd.so.0 = /usr/lib/libesd.so.0 (0x40193000)
libaudiofile.so.0 = /usr/lib/libaudiofile.so.0 (0x4019b000)
libaudio.so.2 = /usr/lib/libaudio.so.2 (0x401bf000)
libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x401d4000)
libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x40226000)
libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x402ed000)
libvga.so.1 = /usr/lib/libvga.so.1 (0x402fb000)
libaa.so.1 = /usr/lib/libaa.so.1 (0x4036)
libasound.so.2 = /usr/lib/libasound.so.2 (0x4037c000)
libm.so.6 = /lib/libm.so.6 (0x4042f000)
libdl.so.2 = /lib/libdl.so.2 (0x40452000)
libpthread.so.0 = /lib/libpthread.so.0 (0x40455000)
libc.so.6 = /lib/libc.so.6 (0x404a6000)
libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x405d9000)
libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x405e2000)
libncurses.so.5 = /lib/libncurses.so.5 (0x405fa000)
libslang.so.1 = /lib/libslang.so.1 (0x40639000)
libgpm.so.1 = /usr/lib/libgpm.so.1 (0x406ac000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000)
([EMAIL PROTECTED])~$
[ sarge / testing ]
([EMAIL PROTECTED])~$ldd /usr/lib/libSDL.so
libm.so.6 = /lib/libm.so.6 (0x400ad000)
libdl.so.2 = /lib/libdl.so.2 (0x400cf000)
libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x400d2000)
libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x4019a000)
libpthread.so.0 = /lib/libpthread.so.0 (0x401a8000)
libc.so.6 = /lib/libc.so.6 (0x401f9000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000)
([EMAIL PROTECTED])~$
Sarge and sid have the same SDL version. You are basically comparing
libsdl1.2debian-all and libsdl1.2debian-oss.
Any reason for such huge disproportions? That's where we got libglib2.0.
Scorched3D built on sarge works fine and doesn't link against libglib2.0.
That's an indirect dependency (brought by libarts), that you won't see
if you pass --as-needed to ld. However, this is not enough, as users
having libsdl1.2debian-{all,arts} installed will still get this
dependency at runtime, probably leading to segfaults.
Also seems that other distros have wxgtk2.4 linked against libglib2.0 and
libsdl doesn't linked against any libglib.
This way most other distros have scorched3d linked against libglib2.0, but
only because wxgtk2.4 and not libsdl.
This may be because they are building a GTK+2.0 version of libwxgtk2.4.
I'm not sure what to do now. Is it possible to link our wxgtk2.4 against
glib2.0? Or unlink libsdl from using libglib?
I'm afraid there is no miracle solution. Getting wxgtk2.5 to install
together with wxgtk2.4, if possible, would be a good option. IIRC, it's
possible to rebuild WxWidgets 2.4 against GTK+ 2.x, but it requires
changes in the applications because of the move to UTF8.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d
On Thursday 24 March 2005 14:37, Bartosz Fenski aka fEnIo wrote: [analysis skipped] I'm not sure what to do now. Is it possible to link our wxgtk2.4 against glib2.0? Or unlink libsdl from using libglib? I found the cause: libSDL.so from libsdl1.2debian-all links against glib2.0 (and much other stuff) libSDL.so from libsdl1.2debian-alsa: zion:~# ldd /usr/lib/libSDL.so | sort /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0xb7e7c000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0xb7e6e000) libasound.so.2 = /usr/lib/libasound.so.2 (0xb7dba000) libc.so.6 = /lib/tls/libc.so.6 (0xb7c52000) libdl.so.2 = /lib/tls/libdl.so.2 (0xb7d95000) libm.so.6 = /lib/tls/libm.so.6 (0xb7d98000) libpthread.so.0 = /lib/tls/libpthread.so.0 (0xb7d86000) zion:~# scorched3d loads fine for me now, I could start a game (though textures were messed up). Looking at Depends of libsdl1.2debian-*, a Conflicts: libsdl1.2debian-all, libsdl1.2debian-arts would probably help. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir ber ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d
On Thu, Mar 24, 2005 at 03:11:32PM +0100, Josselin Mouette wrote:
[...]
Sarge and sid have the same SDL version. You are basically comparing
libsdl1.2debian-all and libsdl1.2debian-oss.
Yes you're right. I didn't notice that I'm using -all on my box.
Any reason for such huge disproportions? That's where we got libglib2.0.
Scorched3D built on sarge works fine and doesn't link against libglib2.0.
That's an indirect dependency (brought by libarts), that you won't see
if you pass --as-needed to ld. However, this is not enough, as users
having libsdl1.2debian-{all,arts} installed will still get this
dependency at runtime, probably leading to segfaults.
So I suppose that Conflicts: libsdl1.2debian-{all,arts} isn't a solution?
ARTS users won't be able to use Scorched3D then :/
Also seems that other distros have wxgtk2.4 linked against libglib2.0 and
libsdl doesn't linked against any libglib.
This way most other distros have scorched3d linked against libglib2.0, but
only because wxgtk2.4 and not libsdl.
This may be because they are building a GTK+2.0 version of libwxgtk2.4.
I'm not sure what to do now. Is it possible to link our wxgtk2.4 against
glib2.0? Or unlink libsdl from using libglib?
I'm afraid there is no miracle solution. Getting wxgtk2.5 to install
together with wxgtk2.4, if possible, would be a good option. IIRC, it's
possible to rebuild WxWidgets 2.4 against GTK+ 2.x, but it requires
changes in the applications because of the move to UTF8.
Hmm, so I wonder how it's done in other distros where wxwidgets uses
gtk2.x. Or maybe they don't use `apt-cache rdepends libwxgtk2.4`?
regards
fEnIo
--
,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo
: :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland
`. `' phone:+48602383548 | proud Debian maintainer and user
`- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001
signature.asc
Description: Digital signature
Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d
On Thu, 24 Mar 2005, Josselin Mouette wrote: I'm not sure what to do now. Is it possible to link our wxgtk2.4 against glib2.0? Or unlink libsdl from using libglib? I'm afraid there is no miracle solution. Getting wxgtk2.5 to install Miracle? no. Technical, sound, and sane? Yes: Version the symbols properly on all libraries that are going to be used by other libraries. Gnome and Kde should have been doing this since day one, since they are the very definition of library hell. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d
Le jeudi 24 mars 2005 14:27 -0300, Henrique de Moraes Holschuh a crit : On Thu, 24 Mar 2005, Josselin Mouette wrote: I'm not sure what to do now. Is it possible to link our wxgtk2.4 against glib2.0? Or unlink libsdl from using libglib? I'm afraid there is no miracle solution. Getting wxgtk2.5 to install Miracle? no. Technical, sound, and sane? Yes: Version the symbols properly on all libraries that are going to be used by other libraries. Yes, adding symbol versioning to Glib is definitely an option. It also means rebuilding all of the incriminated libraries. Gnome and Kde should have been doing this since day one, since they are the very definition of library hell. I don't know for KDE, but the core GNOME libraries now retain full binary compatibility in all versions. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
