Re: Re: multiply defined functions in libs

Yes, because diffferent platforms have different bugs in their memory
implementations.  Also, you need better debugging of memory at runtime on
consoles.

----- Original Message ----- 
From: "Alen Ladavac" <[email protected]>
To: <[email protected]>
Sent: Friday, June 18, 2004 3:48 PM
Subject: Re: [GD-Windows] Re: multiply defined functions in libs


> Sounds a bit obvious, but still... would maybe something like:
>
> #define malloc my_malloc
> #define free my_free
> etc.
>
> work for you? Do you really need your own malloc called even by the code
> that you don't have sources for?
>
> Alen
>
> ----- Original Message -----
> From: "Andras Balogh" <[email protected]>
> To: <[email protected]>
> Cc: <[email protected]>
> Sent: Friday, June 18, 2004 01:06
> Subject: [GD-Windows] Re: multiply defined functions in libs
>
>
> > [note: I moved this thread to gamedevlists-windows]
> >
> > I'm also fighting with this problem right now. For me the linking error
> only
> > happened in the debug build (couldn't figure out why). What I did to
solve
> > this was to link against LIBC instead of LIBCD (since I don't really
need
> > the debug version of that library anyway).. So now I have my own malloc
in
> > place, but this brings some other problems:
> >
> > WinMainCRTStartup calls malloc to allocate some memory, and then uses
the
> > Win32 API function ::HeapSize to query the size of that same memory
> block..
> >
> > So it assumes, that malloc uses ::HeapAlloc with the handle _crtheap,
but
> of
> > course, in this case, it does not (since it is my routine that gets
called
> > instead)
> >
> > So, I'm also stuck.. What can I do? Do I have to roll my own crt
> routines??
> > This sounds a bit too hardcore. I would have thought that many people
use
> > their own memory manager. But how do they solve these things??
> >
> > Any ideas are welcome!
> >
> > Thanks,
> >
> >
> > Andras
> >
> > > -----Original Message-----
> > > From: [email protected]
> > > [mailto:[email protected]] On Behalf Of
> > > Brett Bibby
> > > Sent: Tuesday, June 08, 2004 7:58 PM
> > > To: [email protected]
> > > Subject: [GD-General] multiply defined functions in libs
> > >
> > > I have no idea where to ask this quesiton, so I guess general might be
> > > okay.
> > >
> > > Recently I have switched our memory management to Doug Lea's malloc
and
> so
> > > far so good.  The biggest problem is that I'm trying to drop in and
> > > replace
> > > the normal ansi calls.  This generally works although with different
> side
> > > effects on different platforms.  For example, CodeWarrior's linker
emits
> a
> > > warning that multiple "malloc" symbols are defined on Win32, but
> correctly
> > > chooses to use mine anyway if I set the link order correctly, and
emits
> no
> > > warnings at all on PS2 and GCN and seems to use mine silently
(although
> > > the
> > > original malloc is listed in the linker map, just unused!).  On MSVC
it
> is
> > > an error and won't build the Win32 version.  Since we have 18 target
> > > builds
> > > across mutliple platforms this is messy.  I can't remove the offending
> > > libraries without also removing a bunch of needed functions as they
are
> > > built into a single library.
> > >
> > > Is there any sort of pragma or some other way to make sure that all
> > > references to memory management functions only see my definition?  It
> > > seems
> > > that many people must have done this before....
> > >
> > > If not, the only way I see to fix this properly is to build custom
> release
> > > and debug libs from each platform's source and exclude the functions I
> > > want
> > > to remove <shudder>.
> > >
> > > Brett
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by: GNOME Foundation
> > > Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
> > > GNOME Users and Developers European Conference, 28-30th June in Norway
> > > http://2004/guadec.org
> > > _______________________________________________
> > > Gamedevlists-general mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > > Archives:
> > > http://sourceforge.net/mailarchive/forum.php?forum_id=557
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=555
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Gamedevlists-windows mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Gamedevlists-windows mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=555