-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 24 July 2002 12:30 pm, Lubos Lunak wrote:
> On Tuesday 23 July 2002 03:07, Jon Keating wrote:
> > On Sunday 21 July 2002 02:04 pm, Lubos Lunak wrote:
> > >  I think I understand what the problem is. Maybe a bit tough to solve
> > > though. The reason for the crash is quite simple. LICQ binary has its
> > > own malloc(), coming from libc, and kdelibs have their own (different)
> > > malloc(). After dlopening the KDE GUI module, functions in the module
> > > use different malloc() than those in the main binary, and this leads to
> > > crash (I think it should only crash if the module tries to free
> > > something allocated by the binary or vice versa, but apparently it
> > > happens).
> >
> > Ahh, that makes sense.
>
> [snip]
>
> > So obviously, that is not correct.  Anymore ideas?
>
>  Hmm, yes, -Wl,--export-dynamic wasn't a correct solution, I forgot that
> malloc() is in libc and not in the binary. But I think I have the right
> solution now. There are actually more ways to solve the problem.
>
>  When the dynamic loader resolves symbols, it searches all the libraries in
> the link order, until it finds the symbol. For licq with KDE plugin, the
> libraries are like this:
>
>  licq binary | kde-licq plugin | kdelibs | qt | ... | libc
>
>  There are two malloc() implementation, one in libc, the other in kdelibs.
> When the plugin is not yet loaded, items 2-4 are not there yet, so when
> searching from left to right, malloc() is found only in libc. When the
> plugin is dlopened, the search goes again from left to right, but this time
> malloc() is found already in kdelibs ... => trouble.
>
>  There are three solutions how to make the plugin use the same malloc() as
> the binary :
> - remove malloc() from kdelibs - I don't think there are enough reasons to
> make me do this
> - add malloc() to the binary - both the binary and the plugin will use this
> malloc() (don't forget -Wl,--export-dynamic in this case). You can just
> take kdelibs/kdecore/malloc and use it, if you want.
> - add another malloc() to the plugin, that will skip the faster malloc() in
> kdelibs and use the libc one - see the attached patch and source, they
> belong to licq/plugins/qt-gui/src. Probably the easiest solution.

I'm using the 3rd option since I did not want to put KDE's malloc() into the 
licq binary.  The latest CVS has your patch for the code.  The only concern I 
have is on systems that don't have libc.so or libc.so.6.  Is this anything to 
be concerned about?

Thanks!

Jon

______________________________________________________________
Jon Keating                                                        ICQ #16325723
[EMAIL PROTECTED]                                                       GPG ID: 0x2290A71F
emostar on irc.openprojects.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9P1Ktld1KayKQpx8RAiDvAJ9zzMiNPoVYHqo4QrJjDfEAxVeCQwCg51cB
uBcNgvHRUVHIUPFBiwB4GhU=
=Rhb9
-----END PGP SIGNATURE-----



-------------------------------------------------------
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim
_______________________________________________
Licq-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/licq-devel

Reply via email to