From: Thomas P. <tp...@gm...> - 2002-06-25 11:55:21
|
On Sat, 22 Jun 2002, Federico Fernandez wrote: > Hi all! > > I have a c++ dll and an exe that use the dll. > > If I use STL containers (list), then memory leaks become visible. > > I have got some code that explain this situation. > > Be careful when defining DLL_ACCESS: When compiling the DLL you have to > define it to EXPORT and when compiling the exe you have to define it to > IMPORT. > > Memory leaks can be observed using top on Linux (cross compiling) or the > task viewer in Windows. > > I have read that __USE_MALLOC can be the solution but if I define it I > get undefined symbols > > undefined reference to > `std::__malloc_alloc_template<0>::allocate(unsigned)' > undefined reference to > `std::__malloc_alloc_template<0>::deallocate(void*, unsigned)' > I had no problems with gcc 2.95.3 to define __USE_MALLOC. Couldn't see any memory leaks. I have attached my Makefile. Thomas CXX = i386-mingw32-g++ CFLAGS= -g -D__USE_MALLOC all: main.exe main.exe: main.o exe.o dll.a $(CXX) $(CFLAGS) -o $@ $^ main.o: main.cpp exe.h dll.h $(CXX) -c $(CFLAGS) -o $@ -DDLL_ACCESS="__declspec(dllimport)" $< exe.o: exe.cpp exe.h dll.h $(CXX) -c $(CFLAGS) -o $@ -DDLL_ACCESS="__declspec(dllimport)" $< dll.a: dll.o $(CXX) $(CFLAGS) -o dll.dll -shared -Wl,--out-implib,$@,--output-def,dll.def -DDLL_ACCESS="__declspec(dllexport)" $< dll.o: dll.cpp dll.h $(CXX) -c $(CFLAGS) -o $@ -DDLL_ACCESS="__declspec(dllexport)" $< clean: rm -f *.o dll.a dll.def dll.dll main.exe |
From: Stephen M. W. <ste...@cr...> - 2002-06-25 12:48:11
|
On June 25, 2002 07:55 am, Thomas Pfaff wrote: > > I had no problems with gcc 2.95.3 to define __USE_MALLOC. Couldn't > see any memory leaks. I have attached my Makefile. The default allocator in 2.95 was the malloc_alloc allocator. The default 3.1 allocator is a more sophisticated beast that conforms to the standard (ie. uses 'new' to allocate memory) and has mutex guards against concurrent access. If you build your application using 2.95 and __USE_MALLOC, great, everything matches. If you build with the default 3.1 and define __USE_MALLOC in your code, you will likely run into trouble since your code doesn't match what's in the library. The __USE_MALLOC option is a library build-time option, not a user compile-time option. See http://gcc.gnu.org/onlinedocs/libstdc++/23_containers/howto.html#3 for more. -- Stephen M. Webb |
From: Thomas P. <tp...@gm...> - 2002-06-25 13:12:17
|
On Tue, 25 Jun 2002, Stephen M. Webb wrote: > On June 25, 2002 07:55 am, Thomas Pfaff wrote: > > > > I had no problems with gcc 2.95.3 to define __USE_MALLOC. Couldn't > > see any memory leaks. I have attached my Makefile. > > The default allocator in 2.95 was the malloc_alloc allocator. The > default 3.1 allocator is a more sophisticated beast that conforms to > the standard (ie. uses 'new' to allocate memory) and has mutex guards > against concurrent access. > > If you build your application using 2.95 and __USE_MALLOC, great, > everything matches. If you build with the default 3.1 and define > __USE_MALLOC in your code, you will likely run into trouble since your > code doesn't match what's in the library. > > The __USE_MALLOC option is a library build-time option, not a user > compile-time option. > 3.1 is not the default, it is still beta. Thomas |
From: Stephen M. W. <ste...@cr...> - 2002-06-25 15:16:41
|
On June 25, 2002 09:12 am, Thomas Pfaff wrote: > On Tue, 25 Jun 2002, Stephen M. Webb wrote: > > > > If you build your application using 2.95 and __USE_MALLOC, great, > > everything matches. If you build with the default 3.1 and define > > __USE_MALLOC in your code, you will likely run into trouble since > > your code doesn't match what's in the library. > > > > The __USE_MALLOC option is a library build-time option, not a user > > compile-time option. > > 3.1 is not the default, it is still beta. Er, yes. I meant if you compile your application using a GCC 3.1 that was built with the default settings. As far as I can tell (gcc -v), the GCC 3.1 that comes with the beta release was built with the default libstdc++-v3 settings except that threading was selected and building it as a shared library was disabled, so __USE_MALLOC will break. My point was that using __USE_MALLOC to fix allocation problems with DLLs with GCC 2.95 will have no effect and with GCC 3.1 your application is likely to break. In other words, it is no solution. -- Stephen M. Webb |
From: Thomas P. <tp...@gm...> - 2002-06-25 15:28:49
|
On Tue, 25 Jun 2002, Stephen M. Webb wrote: > On June 25, 2002 09:12 am, Thomas Pfaff wrote: > > On Tue, 25 Jun 2002, Stephen M. Webb wrote: > > > > > > If you build your application using 2.95 and __USE_MALLOC, great, > > > everything matches. If you build with the default 3.1 and define > > > __USE_MALLOC in your code, you will likely run into trouble since > > > your code doesn't match what's in the library. > > > > > > The __USE_MALLOC option is a library build-time option, not a user > > > compile-time option. > > > > 3.1 is not the default, it is still beta. > > Er, yes. I meant if you compile your application using a GCC 3.1 that > was built with the default settings. As far as I can tell (gcc -v), > the GCC 3.1 that comes with the beta release was built with the default > libstdc++-v3 settings except that threading was selected and building > it as a shared library was disabled, so __USE_MALLOC will break. > > My point was that using __USE_MALLOC to fix allocation problems with > DLLs with GCC 2.95 will have no effect and with GCC 3.1 your > application is likely to break. In other words, it is no solution. If i compile the dll and app without __USE_MALLOC it has definitely memory leaks. In other words, this is a solution for 2.95.3 ;-) Thomas |
From: Federico F. <fed...@di...> - 2002-06-26 07:13:59
|
Hi! How can I convert libstdc++.a to libstdc++.dll? I have tried Paul Sokolovsky a2dll script ( http://sourceforge.net/projects/mingwrep/ )but when linking my code I get a huge mountain of unresolved symbols. Paul says that I've got to find all the symbols in the *.h files and prepend "dllimport". Is that true? I can't believe it! Any help? |
From: <dan...@ya...> - 2002-06-26 08:31:20
|
--- Federico Fernandez <fed...@di...> wrote: > Hi! > > How can I convert libstdc++.a to libstdc++.dll? > > I have tried Paul Sokolovsky a2dll script ( > http://sourceforge.net/projects/mingwrep/ )but when linking my code I > get a huge mountain of unresolved symbols. > > Paul says that I've got to find all the symbols in the *.h files and > prepend "dllimport". Is that true? I can't believe it! > > Any help? You can try -Wl,--enable-auto-import when linking. No quarantees. Danny > > > > > > > http://www.sold.com.au - SOLD.com.au - Find yourself a bargain! |
From: Federico F. <fed...@di...> - 2002-06-26 12:00:39
|
What I have done... I have a linux to windows cross compiler (thanks to Jos=E9 Fonseca). mkdir /tmp/stdc++=20 cp $HOME/xmingw32/i386-mingw32msvc/lib/libstdc++.a /tmp/stdc++ cd /tmp/stdc++ i386-mingw32msvc-ar x libstdc++.a i386-mingw32msvc-gcc -shared -o libstdc++.dll *.o i386-mingw32msvc-dlltool --export-all-symbols --output-def libstdc++.def --dllname libstdc++.dll *.o i386-mingw32msvc-dlltool --input-def libstdc++.def --dllname libstdc++.dll --output-lib libstdc++.dll.a cp libstdc++.dll.a libstdc++.dll $HOME/xmingw32/i386-mingw32msvc/lib=20 After all I get unresolved symbols with cout, cerr, clog, etc. I edited iostream and prepend __decl(dllimport) to the extern declaration of such symbols My DLLs now work fine but I have to provide libstdc++.dll. I think it's a little price... (see you at DLL hell !) Thank you all. |
From: Nicolas B. <nic...@ma...> - 2002-06-26 13:06:08
|
Hi, Trying to compile Tcl/Tk from the cvs sources. Tcl compiles ok. Tk used to dump on sh.exe, but that is now fixed with the latest snapshot, (thanx Earnie). Tk now dumps with make.exe, attached is the stackdump Exception: STATUS_ACCESS_VIOLATION at eip=0040C22A eax=00000004 ebx=715554A4 ecx=710A7A90 edx=0022EA88 esi=FFFFFFFF edi=00000000 ebp=0022EAC4 esp=0022EA9C program=C:\msys\bin\make.exe cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023 Stack trace: Frame Function Args 0022EAC4 0040C22A (00000004, 0A02ED08, 000000C8, 00407BBE) 0022EAE4 7108F252 (00000004, 0A02ED08, 000000C8, 00407BEC) 0022EB54 00407C09 (0A02EB68, 0022EB6C, 00407D99, 00407F97) 0022EBB4 00408154 (0022EC3C, 0022EC40, 00000000, 710634F1) 0022EC54 00403B28 (00000000, 0A016B10, FFFFFFFF, 7103030D) 0022EC84 0040443E (0A016B10, 00000000, 0000003A, 71030550) 0022ED24 00403EB5 (00000000, 0A017B08, FFFFFFFF, 00411D9A) 0022ED54 0040443E (0A017B08, 00000000, 0000003A, 710634F1) 0022EDF4 00403EB5 (00000000, 0A017C78, FFFFFFFF, 7103030D) 0022EE24 0040443E (0A017C78, 00000000, 0000003A, 71030550) 0022EEC4 00403EB5 (00000000, 0A027A20, FFFFFFFF, 00411D9A) 0022EEF4 0040447C (0A027A20, 0A020888, 0022EF44, 0040BD53) 0022EF44 0040BEE7 (0A020888, 00000000, 00000000, 00418690) 0022EF74 00402A57 (0A020888, 00000000, 00000001, 00000000) 0022EFA4 004183EB (0A020888, 00000001, 00000008, 00000000) 0022F014 00417AA7 (0A020888, 00000007, 00000000, 00000000) End of stack trace (more stack frames may be present) help appreciated, nicolas boretos |
From: Nicolas B. <nic...@ma...> - 2002-06-26 13:09:52
|
Hi, While I am at it, I just noticed that Tcl now does not compile. This is with the snapshot that fixed the sh.exe dumping... regards, nicolas |