D.gnu - GDC pre-release posted
- David Friedman <d3rdclsmail_a_ _t_earthlink_d_._t_net> Apr 11 2005
- Dejan Lekic <leka entropy.tmok.com> Apr 11 2005
- Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> Apr 12 2005
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Apr 12 2005
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Apr 12 2005
- Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> Apr 12 2005
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Apr 12 2005
- "Charlie" <charles jwavro.com> Apr 12 2005
- bug d.com Apr 12 2005
- David Friedman <d3rdclsmail_a_ _t_earthlink_d_._t_net> Apr 12 2005
- bug d.com Apr 13 2005
- David Friedman <d3rdclsmail_a_ _t_earthlink_d_._t_net> Apr 13 2005
- bug d.com Apr 13 2005
- David Friedman <d3rdclsmail_a_ _t_earthlink_d_._t_net> Apr 24 2005
- bug d.com Apr 24 2005
- David Friedman <d3rdclsmail_a_ _t_earthlink_d_._t_net> Apr 12 2005
- brad domain.invalid Apr 13 2005
Lots of new features, not much documentation. The full release will be made when I sync up with the latest DMD version. http://home.earthlink.net/~dvdfrdmn/d/ Major Improvements: * Updated to DMD 0.113 * Phobos is now built as target library (i.e., no need for a separate build step.) * Boehm-gc is no longer used and the Java package is no longer required. * Inline assembler for x86 (some limitations compared to DMD) * Included Anders Björklund's patches to enable the use of frameworks on Darwin. David
Apr 11 2005
Dejan Lekic <leka entropy.tmok.com> PERFECT! I prefer GPL projects and all I can say is _THANKS_! New GDC version is most welcome... Dejan -- ........... Dejan Lekic http://dejan.lekic.org
Apr 11 2005
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Friedman schrieb am Tue, 12 Apr 2005 00:03:40 -0400:Lots of new features, not much documentation. The full release will be made when I sync up with the latest DMD version. http://home.earthlink.net/~dvdfrdmn/d/ Major Improvements: * Updated to DMD 0.113 * Phobos is now built as target library (i.e., no need for a separate build step.) * Boehm-gc is no longer used and the Java package is no longer required. * Inline assembler for x86 (some limitations compared to DMD) * Included Anders Björklund's patches to enable the use of frameworks on Darwin.
Thank's a lot for your great work David. Somehow Phobos' configure set the target_alias but didn't set the host_alias and as a consequence make tried to create /gcc instead of i686-pc-linux-gnu/gcc. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFCW8/Z3w+/yD4P9tIRAkG6AJ9Zerq5xY1jM1NyUQJvSCVfYlbqzQCeJy7a 8JPFx7KHK6UIG6MAIPMkY4Q= =2Hgj -----END PGP SIGNATURE-----
Apr 12 2005
Thomas Kuehne wrote:Somehow Phobos' configure set the target_alias but didn't set the host_alias and as a consequence make tried to create /gcc instead of i686-pc-linux-gnu/gcc.
Thanks Thomas, this got me a little further... (explicitly setting --host and --build params) Now it seems to be disliking my paths instead: i386-redhat-linux-gcc -o internal/gc/gc.o -O2 -g -pipe -march=i386 -funittest -nostdinc -I ../gcc-3.4.3/gcc/d/phobos -I ../gcc-3.4.3/gcc/d/phobos/internal/gc -I ./i386-redhat-linux -c ../gcc-3.4.3/gcc/d/phobos/internal/gc/gc.d {standard input}: Assembler messages: {standard input}:10: Error: unknown pseudo-op: `..' make: *** [internal/gc/gc.o] Error 1 It's really, really hard to try to pass the standard CFLAGS and DFLAGS to anything in D ? (having similar problems with DMD and recls) --anders
Apr 12 2005
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anders F Björklund schrieb am Tue, 12 Apr 2005 15:56:25 +0200:Now it seems to be disliking my paths instead: i386-redhat-linux-gcc -o internal/gc/gc.o -O2 -g -pipe -march=i386 -funittest -nostdinc -I ../gcc-3.4.3/gcc/d/phobos -I ../gcc-3.4.3/gcc/d/phobos/internal/gc -I ./i386-redhat-linux -c ../gcc-3.4.3/gcc/d/phobos/internal/gc/gc.d {standard input}: Assembler messages: {standard input}:10: Error: unknown pseudo-op: `..' make: *** [internal/gc/gc.o] Error 1
guessing from the error message your directory setup would be somewhere/gcc-3.4.3 somewhere/gcc-3.4.3/gcc/d/phobos somewhere/phobos [you are here and trying to build Phobos] Is that right? Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFCW9j93w+/yD4P9tIRAtdVAKCaxfmIifnbwZTuKdQGSIf4SEXNwACfXCBl 9YM/Vgdo3SSoVv4rT2Q8rRQ= =Ujhp -----END PGP SIGNATURE-----
Apr 12 2005
Thomas Kuehne wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anders F Björklund schrieb am Tue, 12 Apr 2005 15:56:25 +0200:Now it seems to be disliking my paths instead: i386-redhat-linux-gcc -o internal/gc/gc.o -O2 -g -pipe -march=i386 -funittest -nostdinc -I ../gcc-3.4.3/gcc/d/phobos -I ../gcc-3.4.3/gcc/d/phobos/internal/gc -I ./i386-redhat-linux -c ../gcc-3.4.3/gcc/d/phobos/internal/gc/gc.d {standard input}: Assembler messages: {standard input}:10: Error: unknown pseudo-op: `..' make: *** [internal/gc/gc.o] Error 1
guessing from the error message your directory setup would be somewhere/gcc-3.4.3 somewhere/gcc-3.4.3/gcc/d/phobos somewhere/phobos [you are here and trying to build Phobos] Is that right? Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFCW9j93w+/yD4P9tIRAtdVAKCaxfmIifnbwZTuKdQGSIf4SEXNwACfXCBl 9YM/Vgdo3SSoVv4rT2Q8rRQ= =Ujhp -----END PGP SIGNATURE-----
Argh, I forgot to mention this: The build process has changed and there is no need to build Phobos separately. The INSTALL file has been updated and explains the new process. Don't worry, it's a lot easier now. David
Apr 12 2005
David Friedman wrote:Argh, I forgot to mention this: The build process has changed and there is no need to build Phobos separately. The INSTALL file has been updated and explains the new process. Don't worry, it's a lot easier now.
Yeah, ended up actually *reading* the INSTALL when the build failed :-) And with a little luck, it should be no longer needed to provide a /opt/gdc/gcc and /opt/gdc/g++ for Mac OS X... That should cut down the download size for GDC, from 30 MB to a tiny 3 MB or something! The vanilla build completed on Mac OS X, so I will test that later on... --anders
Apr 12 2005
Thomas Kuehne wrote:guessing from the error message your directory setup would be somewhere/gcc-3.4.3 somewhere/gcc-3.4.3/gcc/d/phobos somewhere/phobos [you are here and trying to build Phobos] Is that right?
Actually my set up is: (done by the RPM specfile, you see...) BUILD/ gdc-0.11pre1-gcc-3.4.3/ gcc-3.4.3 obj-i386-redhat-linux gdc-temp phobos-unittest phobos-contracts phobos-release Where gcc-3.4.3 are the patched GCC/GDC sources, unpacked from gcc-core-%{gcc_version}.tar.bz2 and gcc-g++-%{gcc_version}.tar.bz2, and then gdc-%{gdc_version}.tar.bz2 is added as "gcc-?.?.?/gcc/d" And I'm building GCC/GDC in the "obj-%{_target_platform}" directory, and temporarily installing it in the "gdc-temp" directory to build Phobos in the "phobos-***" and the "phobos-release" directories... But I will fall back to building a vanilla version, since it seems that David has added a new toplev patch and that my Make hacks don't work: make libphobos.a unittest \ CC="gcc" CFLAGS="$OPT_FLAGS -DPHOBOS_USE_PTHREADS=1 -DHAVE_CONFIG_H -Ietc/c/stlsoft -I." \ DMD="gdc" DFLAGS="$OPT_FLAGS -funittest -nostdinc" ./unittest || exit 1 It's possible that this can be made simpler now, with the new "check-target-libphobos" Maybe one can even pass the flags directly to configure, now that the whining "boehm-gc" target is not needed anymore ? Who knows, maybe it can even be built with "make -j3" now... All that I *really* want to do is to pass $OPT_FLAGS along to the various C/C++/D builds - it is currently constructed from $RPM_OPT_FLAGS, minus all flags that GCC and libiberty hates: OPT_FLAGS=`echo $RPM_OPT_FLAGS|sed -e 's/-fno-rtti//g' -e 's/-fno-exceptions//g'` # -mcpu makes libiberty fail to build, in GCC 3.4 *grr!* OPT_FLAGS=`echo $OPT_FLAGS|perl -pe 's/ ?-mcpu=([^ ]+)//g'` Where the standard i386 $RPM_OPT_FLAGS is: #rpm --eval %{optflags} -O2 -g -pipe -march=i386 -mcpu=i686 Then I use the setting of "-funittest" for phobos-unittest, "" for phobos-contracts and "-frelease" for phobos-release ? Rest of the flags crud was just added to make it limp along... --anders
Apr 12 2005
David Friedman wrote:Lots of new features, not much documentation. The full release will be made when I sync up with the latest DMD version.
I get this error when trying to build Phobos: "configure: error: Sorry, you must provide the target-specific configure fragments (--enable-phobos-config-dir)" I tried adding --disable-phobos-config-dir, but that didn't help much... And making it a fake directory just made "frag-unix not found". --anders
Apr 12 2005
David Friedman wrote:* Included Anders Björklund's patches to enable the use of frameworks on Darwin.
In case anyone wonders, the patch is just to make GCC/GDC pass any -framework on to the system linker, to avoid the clunky alternative: "-framework Whatever" => "-Wl,-framework,Whatever" It just makes doing GDC things a little nicer on the Mac OS X platform. Especially with the new fix to make it co-exist with Apple's GCC/G++ ! --anders
Apr 12 2005
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Friedman schrieb am Tue, 12 Apr 2005 00:03:40 -0400:Lots of new features, not much documentation. The full release will be made when I sync up with the latest DMD version. http://home.earthlink.net/~dvdfrdmn/d/
FYI http://dstress.kuehne.cn/raw_results/linux-i686_gdc-0.11pre http://dstress.kuehne.cn/raw_results/linux-i686_gdc-0.11pre.log Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFCW+Sy3w+/yD4P9tIRAqvJAJ41YaZMHnkCl57GyKAVayE0IkPbFgCdH3Px fW+phdVz3xZCSEUPi8gPUJY= =nHdx -----END PGP SIGNATURE-----
Apr 12 2005
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1David Friedman schrieb am Tue, 12 Apr 2005 00:03:40 -0400:Lots of new features, not much documentation. The full release will be made when I sync up with the latest DMD version. http://home.earthlink.net/~dvdfrdmn/d/
FYI http://dstress.kuehne.cn/raw_results/linux-i686_gdc-0.11pre http://dstress.kuehne.cn/raw_results/linux-i686_gdc-0.11pre.log
Thanks to Anders: http://dstress.kuehne.cn/raw_results/mac-OS-X-10.3.7_gdc-0.11pre http://dstress.kuehne.cn/raw_results/mac-OS-X-10.3.7_gdc-0.11pre.log Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFCW/z73w+/yD4P9tIRAtFRAKDHnRn0V/T1xL5k5B4tudvvMwhupACgu19o HF0tc7TJeEYjA05VJeu8xVM= =bU1P -----END PGP SIGNATURE-----
Apr 12 2005
Thomas Kuehne wrote:Thanks to Anders: http://dstress.kuehne.cn/raw_results/mac-OS-X-10.3.7_gdc-0.11pre http://dstress.kuehne.cn/raw_results/mac-OS-X-10.3.7_gdc-0.11pre.log
Actually it was 10.3.8, but there's not really any real difference. "Panther"... BTW, 10.4 Tiger - with GCC 4.0 - was announced today! --anders
Apr 12 2005
Anders F Björklund wrote:Thomas Kuehne wrote:Thanks to Anders: http://dstress.kuehne.cn/raw_results/mac-OS-X-10.3.7_gdc-0.11pre http://dstress.kuehne.cn/raw_results/mac-OS-X-10.3.7_gdc-0.11pre.log
Actually it was 10.3.8, but there's not really any real difference. "Panther"... BTW, 10.4 Tiger - with GCC 4.0 - was announced today! --anders
Tyger! Tyger! burning bright I'm shelling out 130 bucks tonight :-p
Apr 12 2005
David Friedman wrote:Lots of new features, not much documentation. The full release will be made when I sync up with the latest DMD version.
I don't think you need to do that. You can release this as gdc 0.11 ? And then release DMD 0.120 compatibility as gdc 0.12 "pre" instead...Major Improvements: * Included Anders Björklund's patches to enable the use of frameworks on Darwin.
(and from the GDC home page: )# On Darwin, D object code can be linked with the system gcc. Likewise, gdc can link C++ object code built by the system g++.
This is most *excellent* news! Now you can build a link D programs with regular C libraries and system frameworks, without the need for a custom GCC build installed on the system. Works just great! The download/install also shrinked considerable, compared to 0.10: Binaries: 8.0K /opt/gdc/bin/dmd 288K /opt/gdc/bin/gdc 2.0M /opt/gdc/include/d 2.3M /opt/gdc/lib/libphobos.a 4.0K /opt/gdc/lib/libphobos.spec 3.1M /opt/gdc/lib/gcc-lib/powerpc-apple-darwin7.8.0/3.3.5/cc1d 4.0K /opt/gdc/lib/gcc-lib/powerpc-apple-darwin7.8.0/3.3.5/crt2.o 4.0K /opt/gdc/share/man/man1/dmd.1 4.0K /opt/gdc/share/man/man1/gdc.1 ==== 2.0M gdc.zip Sources: 11M gcc-core-3.3.5.tar.bz2 2.1M gcc-g++-3.3.5.tar.bz2 788K gdc-0.11pre1.tar.bz2 One might even consider "promoting" GDC back up to /usr again... Since now it wouldn't interfere with the system C/C++ compilers. But compiling D is now as simple as a /opt/gdc/bin/gdc, anyway. D usability on the Mac OS X platform climbed up a whole ladder! Now all we need is those D name-mangling patches for GDC, but they seem to be coming along just nicely on Dsource ? http://www.dsource.org/forums/viewforum.php?f=58 (demangler is done, "just" integration left todo) --anders
Apr 12 2005
Anders F Björklund wrote:David Friedman wrote:Lots of new features, not much documentation. The full release will be made when I sync up with the latest DMD version.
I don't think you need to do that. You can release this as gdc 0.11 ? And then release DMD 0.120 compatibility as gdc 0.12 "pre" instead...
I still need to fix some bugs and update the documentation (including your man pages ;-) DavidMajor Improvements: * Included Anders Björklund's patches to enable the use of frameworks on Darwin.
(and from the GDC home page: )# On Darwin, D object code can be linked with the system gcc. Likewise, gdc can link C++ object code built by the system g++.
This is most *excellent* news! Now you can build a link D programs with regular C libraries and system frameworks, without the need for a custom GCC build installed on the system. Works just great! The download/install also shrinked considerable, compared to 0.10: Binaries: 8.0K /opt/gdc/bin/dmd 288K /opt/gdc/bin/gdc 2.0M /opt/gdc/include/d 2.3M /opt/gdc/lib/libphobos.a 4.0K /opt/gdc/lib/libphobos.spec 3.1M /opt/gdc/lib/gcc-lib/powerpc-apple-darwin7.8.0/3.3.5/cc1d 4.0K /opt/gdc/lib/gcc-lib/powerpc-apple-darwin7.8.0/3.3.5/crt2.o 4.0K /opt/gdc/share/man/man1/dmd.1 4.0K /opt/gdc/share/man/man1/gdc.1 ==== 2.0M gdc.zip Sources: 11M gcc-core-3.3.5.tar.bz2 2.1M gcc-g++-3.3.5.tar.bz2 788K gdc-0.11pre1.tar.bz2 One might even consider "promoting" GDC back up to /usr again... Since now it wouldn't interfere with the system C/C++ compilers. But compiling D is now as simple as a /opt/gdc/bin/gdc, anyway. D usability on the Mac OS X platform climbed up a whole ladder! Now all we need is those D name-mangling patches for GDC, but they seem to be coming along just nicely on Dsource ? http://www.dsource.org/forums/viewforum.php?f=58 (demangler is done, "just" integration left todo) --anders
Apr 12 2005
David Friedman wrote:
I don't think you need to do that. You can release this as gdc 0.11 ? And then release DMD 0.120 compatibility as gdc 0.12 "pre" instead...
I still need to fix some bugs and update the documentation (including your man pages ;-)
I meant "fix the bugs in this one, *then* release it as 0.11" :-) And wait with the new DMD features and stuff for 0.12 instead ? (Assuming that it would be easier to release 0.11 without them) --anders
Apr 12 2005
A mingwn build soon to follow :) ? Charlie "David Friedman" <d3rdclsmail_a_ _t_earthlink_d_._t_net> wrote in message news:d3fh9n$1gur$1 digitaldaemon.com...Lots of new features, not much documentation. The full release will be made when I sync up with the latest DMD version. http://home.earthlink.net/~dvdfrdmn/d/ Major Improvements: * Updated to DMD 0.113 * Phobos is now built as target library (i.e., no need for a separate build step.) * Boehm-gc is no longer used and the Java package is no longer required. * Inline assembler for x86 (some limitations compared to DMD) * Included Anders Björklund's patches to enable the use of frameworks on Darwin. David
Apr 12 2005
Tried the pre-release with my example large file. cc1d reports: virtual memory exhausted: Cannot allocate memory Even though I have ~350M phisical free memory as shown by top. gdc fails after about 250M allocation. What's the flag I should pass to "configure" to build a debugging version of gdc? I can try to generate the stack trace of gdc itself when it fails. Do you think this will help?
Apr 12 2005
bug d.com wrote:Tried the pre-release with my example large file. cc1d reports: virtual memory exhausted: Cannot allocate memory Even though I have ~350M phisical free memory as shown by top. gdc fails after about 250M allocation. What's the flag I should pass to "configure" to build a debugging version of gdc? I can try to generate the stack trace of gdc itself when it fails. Do you think this will help?
A stack trace will definately be helpful. Setting the CFLAGS environment variable to '-O0 -g' before running configure should work. You could also uncomment 'D_CC_FLAGS += -O0 -g' in d/Make-lang.in. David
Apr 12 2005
This problem also doesn't work under gdc: digitalmars.D/21401 Some info regarding my bug with large files: I have lot's of things like (T/A/B) as described in the above. Separate compilation always gives many errors like: b.d:9: size of type T!(B) is not known b.d:9: size of type T!(B) is not known I'm not sure if this is a bug or feature? (both DMD and GDC behave the same.) So I wrote a script to generate all of them into one big file, then DMD works. But GDC fails with: "virtual memory exhausted: Cannot allocate memory". By setting CFLAGS='-O0 -g', I was able to debug gdc, but I don't know where to set breakpoint. Detaching after fork from child process 20376. virtual memory exhausted: Cannot allocate memory Program exited with code 01. (gdb) Grep the error message doesn't give me much help, there are many occurance of "virtual memory exhausted", but not occurance of "Cannot allocate memory". Can you give me some hint here, where to set break point to catch the stack trace?
Apr 13 2005
bug d.com wrote:This problem also doesn't work under gdc: digitalmars.D/21401 Some info regarding my bug with large files: I have lot's of things like (T/A/B) as described in the above. Separate compilation always gives many errors like: b.d:9: size of type T!(B) is not known b.d:9: size of type T!(B) is not known I'm not sure if this is a bug or feature? (both DMD and GDC behave the same.) So I wrote a script to generate all of them into one big file, then DMD works. But GDC fails with: "virtual memory exhausted: Cannot allocate memory". By setting CFLAGS='-O0 -g', I was able to debug gdc, but I don't know where to set breakpoint. Detaching after fork from child process 20376. virtual memory exhausted: Cannot allocate memory Program exited with code 01. (gdb) Grep the error message doesn't give me much help, there are many occurance of "virtual memory exhausted", but not occurance of "Cannot allocate memory". Can you give me some hint here, where to set break point to catch the stack trace?
The program to run in gdb is 'cc1d'. You can run gdc with the '-v' option to see what the exact command line for cc1d is. Then set breakpoints on 'exit' and 'perror'. David
Apr 13 2005
In article <d3kfqs$2ptg$1 digitaldaemon.com>, David Friedman says...The program to run in gdb is 'cc1d'. You can run gdc with the '-v' option to see what the exact command line for cc1d is. Then set breakpoints on 'exit' and 'perror'.
Ah, I tried to set BP on 'exit' and 'perror' before with gdc, now I know why it doesn't work :-) Here is the stack trace I got by watching cc1d. If you need any more info, let me know. Thanks. ------------------------------------------------------------------------- (gdb) b perror Breakpoint 2 at 0x4015f256 (gdb) b exit Breakpoint 3 at 0x4013a386 (gdb) cont Continuing. GNU D version 3.3.5 (i686-pc-linux-gnu) compiled by GNU C version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6). GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32768 cc1d: out of memory allocating 4072 bytes after a total of 199913472 bytes Breakpoint 3, 0x4013a386 in exit () from /lib/libc.so.6 (gdb) where #0 0x4013a386 in exit () from /lib/libc.so.6 #1 0x08396eb9 in xexit (code=1) at xexit.c:52 #2 0x08396d3d in xmalloc_failed (size=4072) at xmalloc.c:132 #3 0x08396d6f in xmalloc (size=4072) at xmalloc.c:145 #4 0x401740e1 in _obstack_newchunk () from /lib/libc.so.6 #5 0x082ab8fb in new_insn_chain () at reload1.c:532 #6 0x08366405 in build_insn_chain (first=0x43c93840) at global.c:1826 #7 0x082e679e in rest_of_compilation (decl=0x4174f1c0) at toplev.c:3320 #8 0x080c86ed in FuncDeclaration::toObjFile() (this=0xe1eb1e8) at d/d-glue.cc:1967 #9 0x0804bd35 in AttribDeclaration::toObjFile() (this=0xe1eb190) at d/dmd/attrib.c:129 #10 0x080b3575 in ClassDeclaration::toObjFile() (this=0xe1e1490) at d/dmd/toobj.c:211 #11 0x080b04d4 in TemplateInstance::toObjFile() (this=0x8626c48) at d/dmd/template.c:1829 #12 0x080c8884 in Module::genobjfile() (this=0x8520ad0) at d/d-glue.cc:2217 #13 0x080b7d7e in d_parse_file(int) () at d/d-lang.cc:815 #14 0x082e4846 in compile_file () at toplev.c:2130 #15 0x082ea225 in do_compile () at toplev.c:5414 #16 0x082ea278 in toplev_main (argc=23, argv=0xbfffecb4) at toplev.c:5444 #17 0x080df626 in main (argc=23, argv=0xbfffecb4) at main.c:35 (gdb)
Apr 13 2005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit bug d.com wrote:In article <d3kfqs$2ptg$1 digitaldaemon.com>, David Friedman says...The program to run in gdb is 'cc1d'. You can run gdc with the '-v' option to see what the exact command line for cc1d is. Then set breakpoints on 'exit' and 'perror'.
Ah, I tried to set BP on 'exit' and 'perror' before with gdc, now I know why it doesn't work :-) Here is the stack trace I got by watching cc1d. If you need any more info, let me know. Thanks. ------------------------------------------------------------------------- (gdb) b perror Breakpoint 2 at 0x4015f256 (gdb) b exit Breakpoint 3 at 0x4013a386 (gdb) cont Continuing. GNU D version 3.3.5 (i686-pc-linux-gnu) compiled by GNU C version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6). GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32768 cc1d: out of memory allocating 4072 bytes after a total of 199913472 bytes Breakpoint 3, 0x4013a386 in exit () from /lib/libc.so.6 (gdb) where #0 0x4013a386 in exit () from /lib/libc.so.6 #1 0x08396eb9 in xexit (code=1) at xexit.c:52 #2 0x08396d3d in xmalloc_failed (size=4072) at xmalloc.c:132 #3 0x08396d6f in xmalloc (size=4072) at xmalloc.c:145 #4 0x401740e1 in _obstack_newchunk () from /lib/libc.so.6 #5 0x082ab8fb in new_insn_chain () at reload1.c:532 #6 0x08366405 in build_insn_chain (first=0x43c93840) at global.c:1826 #7 0x082e679e in rest_of_compilation (decl=0x4174f1c0) at toplev.c:3320 #8 0x080c86ed in FuncDeclaration::toObjFile() (this=0xe1eb1e8) at d/d-glue.cc:1967 #9 0x0804bd35 in AttribDeclaration::toObjFile() (this=0xe1eb190) at d/dmd/attrib.c:129 #10 0x080b3575 in ClassDeclaration::toObjFile() (this=0xe1e1490) at d/dmd/toobj.c:211 #11 0x080b04d4 in TemplateInstance::toObjFile() (this=0x8626c48) at d/dmd/template.c:1829 #12 0x080c8884 in Module::genobjfile() (this=0x8520ad0) at d/d-glue.cc:2217 #13 0x080b7d7e in d_parse_file(int) () at d/d-lang.cc:815 #14 0x082e4846 in compile_file () at toplev.c:2130 #15 0x082ea225 in do_compile () at toplev.c:5414 #16 0x082ea278 in toplev_main (argc=23, argv=0xbfffecb4) at toplev.c:5444 #17 0x080df626 in main (argc=23, argv=0xbfffecb4) at main.c:35 (gdb)
Here's something else to try: Apply this patch to gcc/ggc-page.c and rebuild. There's no need to run it in gdb; just try compiling the source file. If it works, it means I have a garbage collection bug. David
Apr 24 2005
Tried, the same problem: virtual memory exhausted: Cannot allocate memory But the line number is different, I'm using gcc-3.3.5.Here's something else to try: Apply this patch to gcc/ggc-page.c and rebuild. There's no need to run it in gdb; just try compiling the source file. If it works, it means I have a garbage collection bug. David --------------010200080606090909070300 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="gcc-page.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gcc-page.patch" *** ggc-page.c.orig Tue Apr 19 19:14:34 2005 --- ggc-page.c Sun Apr 24 15:24:37 2005 *************** *** 1774,1779 **** --- 1774,1780 ---- void ggc_collect (void) { + return; /* Avoid frequent unnecessary work by skipping collection if the total allocations haven't expanded much since the last collection. */ --------------010200080606090909070300--
Apr 24 2005
Because this was a pre-release and there are still some outstanding issues, I didn't want to announce it just yet... But yes, you can at least build a cross compiler with a mingw32 target now. I haven't tried a native build under MSYS/Cygwin. BTW, this is the only cross target currently supported 'out of the box'. David Charlie wrote:A mingwn build soon to follow :) ? Charlie "David Friedman" <d3rdclsmail_a_ _t_earthlink_d_._t_net> wrote in message news:d3fh9n$1gur$1 digitaldaemon.com...Lots of new features, not much documentation. The full release will be made when I sync up with the latest DMD version. http://home.earthlink.net/~dvdfrdmn/d/ Major Improvements: * Updated to DMD 0.113 * Phobos is now built as target library (i.e., no need for a separate build step.) * Boehm-gc is no longer used and the Java package is no longer required. * Inline assembler for x86 (some limitations compared to DMD) * Included Anders Björklund's patches to enable the use of frameworks on Darwin. David
Apr 12 2005
David Friedman wrote:Lots of new features, not much documentation. The full release will be made when I sync up with the latest DMD version. http://home.earthlink.net/~dvdfrdmn/d/ Major Improvements: * Updated to DMD 0.113 * Phobos is now built as target library (i.e., no need for a separate build step.) * Boehm-gc is no longer used and the Java package is no longer required. * Inline assembler for x86 (some limitations compared to DMD) * Included Anders Björklund's patches to enable the use of frameworks on Darwin. David
I just wanted to say thank you for all the work that you have put in to GDC. Thanks Brad
Apr 13 2005