D.gnu - GDC release 1f
- David Friedman <d3rdclsmail earthlink.net> Apr 22 2004
- s31552 mail.ecc.u-tokyo.ac.jp Apr 22 2004
- David Friedman <d3rdclsmail earthlink.net> Apr 23 2004
- Lws <eluusive sbcglobal.net> Apr 23 2004
- David Friedman <d3rdclsmail earthlink.net> Apr 23 2004
- Lws <eluusive sbcglobal.net> Apr 23 2004
- Lws <eluusive sbcglobal.net> Apr 23 2004
- Brian Pomerantz <bapper piratehaven.org> Apr 23 2004
- Stephan Wienczny <wienczny web.de> Apr 24 2004
- David Friedman <d3rdclsmail earthlink.net> Apr 24 2004
- Stephan Wienczny <wienczny web.de> Apr 25 2004
- David Friedman <d3rdclsmail earthlink.net> Apr 26 2004
- Stephan Wienczny <wienczny web.de> Apr 26 2004
- David Friedman <d3rdclsmail earthlink.net> Apr 26 2004
- s31552 mail.ecc.u-tokyo.ac.jp Apr 24 2004
- s31552 mail.ecc.u-tokyo.ac.jp Apr 24 2004
- s31552 mail.ecc.u-tokyo.ac.jp Apr 27 2004
- "Jeroen van Bemmel" <someone somewhere.com> May 18 2004
- "Kris" <someidiot earthlink.dot.dot.dot.net> Jul 13 2004
- David Friedman <d3rdclsmail earthlink.net> Jul 15 2004
- kpuchar <kpuchar poczta.gazeta.pl> Jul 23 2004
Phew! The web page has been updated with a new release. Major highlights: * Reported crashes have been fixed * Update to 0.82 * Compiler no longer requires long double floating point routines * Included parts of the Boehm garbage collector to get the stack and data extents. The compiler and library now build on Cygwin and FreeBSD. Other Unix-like environments should work too. David
Apr 22 2004
The compiler and library now build on Cygwin and FreeBSD. Other Unix-like environments should work too.
Great! But d/phobos/boehm-gc is dead symbolic link. I think you should use 'tar -cvzhf'. ------------------ shinichiro.h s31552 mail.ecc.u-tokyo.ac.jp
Apr 22 2004
Do you have the Java package for gcc? I should have mentioned in the post that it is required now. When the package is extracted in the gcc directory, the link should point to <srcdir>/boehm-gc. David s31552 mail.ecc.u-tokyo.ac.jp wrote:The compiler and library now build on Cygwin and FreeBSD. Other Unix-like environments should work too.
Great! But d/phobos/boehm-gc is dead symbolic link. I think you should use 'tar -cvzhf'. ------------------ shinichiro.h s31552 mail.ecc.u-tokyo.ac.jp
Apr 23 2004
On 2004-04-23 05:07:31 -0700, David Friedman <d3rdclsmail earthlink.net> said:Do you have the Java package for gcc? I should have mentioned in the post that it is required now. When the package is extracted in the gcc directory, the link should point to <srcdir>/boehm-gc.
Why is the Java package required? You can't compile boehm-gc on MacOS X. At least it says: This configuration is not supported in the following directories: .... boehm-gc ... Anyway I'm still compiling.
Apr 23 2004
An extra note: there are some extra build requirements and the install instructions have changed a bit. David Friedman wrote:Phew! The web page has been updated with a new release. Major highlights: * Reported crashes have been fixed * Update to 0.82 * Compiler no longer requires long double floating point routines * Included parts of the Boehm garbage collector to get the stack and data extents. The compiler and library now build on Cygwin and FreeBSD. Other Unix-like environments should work too. David
Apr 23 2004
On 2004-04-22 21:59:04 -0700, David Friedman <d3rdclsmail earthlink.net> said:Phew! The web page has been updated with a new release. Major highlights: * Reported crashes have been fixed * Update to 0.82 * Compiler no longer requires long double floating point routines * Included parts of the Boehm garbage collector to get the stack and data extents. The compiler and library now build on Cygwin and FreeBSD. Other Unix-like environments should work too. David
gdc 1f allowed me to get phobos compiled.. But now i've got this problem: --begin hello.d import std.stream; int main(char[][] args) { stdout.writeLine("Hello World!"); return 0; } --end hello.d gdc hello.d -o hello /usr/bin/ld: /usr/local/gdc/lib/gcc-lib/powerpc-apple-darwin7.3.0/3.3.3/../../../lib hobos.a(d_os_dep.o) section's (__TEXT,__eh_frame) type S_COALESCED does not match previous objects type S_REGULAR /usr/bin/ld: /usr/local/gdc/lib/gcc-lib/powerpc-apple-darwin7.3.0/3.3.3/../../../l bphobos.a(d_init.o) section's (__TEXT,__eh_frame) type S_COALESCED does not match previous objects type S_REGULAR collect2: ld returned 1 exit status Any ideas? I'm compiling against gcc 3.3.3
Apr 23 2004
On 2004-04-23 10:41:27 -0700, Lws <eluusive sbcglobal.net> said:On 2004-04-22 21:59:04 -0700, David Friedman <d3rdclsmail earthlink.net> said:Phew! The web page has been updated with a new release. Major highlights: * Reported crashes have been fixed * Update to 0.82 * Compiler no longer requires long double floating point routines * Included parts of the Boehm garbage collector to get the stack and data extents. The compiler and library now build on Cygwin and FreeBSD. Other Unix-like environments should work too. David
gdc 1f allowed me to get phobos compiled.. But now i've got this problem: --begin hello.d import std.stream; int main(char[][] args) { stdout.writeLine("Hello World!"); return 0; } --end hello.d gdc hello.d -o hello /usr/bin/ld: /usr/local/gdc/lib/gcc-lib/powerpc-apple-darwin7.3.0/3.3.3/../../../lib hobos.a(d_os_dep.o) section's (__TEXT,__eh_frame) type S_COALESCED does not match previous objects type S_REGULAR /usr/bin/ld: /usr/local/gdc/lib/gcc-lib/powerpc-apple-darwin7.3.0/3.3.3/../../../l bphobos.a(d_init.o) section's (__TEXT,__eh_frame) type S_COALESCED does not match previous objects type S_REGULAR collect2: ld returned 1 exit status Any ideas? I'm compiling against gcc 3.3.3
I don't know what was wrong, but i desided to try recompiling phobos again. This time it works.. *Bog*
Apr 23 2004
David Friedman wrote:Phew! The web page has been updated with a new release. Major highlights:
Excellent! Shared libraries on Linux appear to work properly now (was crashing on what I assumed was the garbage collecting). BAPper
Apr 23 2004
David Friedman wrote:Phew! The web page has been updated with a new release. Major highlights: * Reported crashes have been fixed * Update to 0.82 * Compiler no longer requires long double floating point routines * Included parts of the Boehm garbage collector to get the stack and data extents. The compiler and library now build on Cygwin and FreeBSD. Other Unix-like environments should work too. David
I got gdc compiled using gcc-3.3.3 and gcc-3.4.0, but I can't get phobos to be configured correctly. ./configure outputs: ... ... configure: configuring in boehm-gc configure: running /bin/sh './configure' --prefix=/usr/local 'CC=gcc' 'CXX=g++' --cache-file=/dev/null --srcdir=. configure: warning: CC=gcc: invalid host type configure: warning: CXX=g++: invalid host type configure: error: can only configure for one host and one target at a time configure: error: /bin/sh './configure' failed for boehm-gc Stephan
Apr 24 2004
Try unsetting the 'CC' and 'CXX' environment variables before running configure. Phobos should be built with the same version of gcc/g++/gdc. Stephan Wienczny wrote:David Friedman wrote:Phew! The web page has been updated with a new release. Major highlights: * Reported crashes have been fixed * Update to 0.82 * Compiler no longer requires long double floating point routines * Included parts of the Boehm garbage collector to get the stack and data extents. The compiler and library now build on Cygwin and FreeBSD. Other Unix-like environments should work too. David
I got gdc compiled using gcc-3.3.3 and gcc-3.4.0, but I can't get phobos to be configured correctly. ./configure outputs: ... ... configure: configuring in boehm-gc configure: running /bin/sh './configure' --prefix=/usr/local 'CC=gcc' 'CXX=g++' --cache-file=/dev/null --srcdir=. configure: warning: CC=gcc: invalid host type configure: warning: CXX=g++: invalid host type configure: error: can only configure for one host and one target at a time configure: error: /bin/sh './configure' failed for boehm-gc Stephan
Apr 24 2004
David Friedman wrote:Try unsetting the 'CC' and 'CXX' environment variables before running configure. Phobos should be built with the same version of gcc/g++/gdc.
After unsetting 'CC' and 'CXX' boehm-gc could be configured, but another error occoured when compiling thread.d. In line 645 is 'Semaphore' undefined. I think that something in gcc.threadsem.d is wrong. gdc was configure with --enable-threads=posix. What is the differnece between POSIX semaphores and PThread (Posix Thread) semaphores? Could it be a problem that I'm using nptl (Native Posix Threading Library) which is build into glibc?
Apr 25 2004
It seems like the conifgure script is not setting up the sempahore implementation. GDC/Phobos does not use the --enable-threads option yet, so that shouldn't be causing any problems. Please send me the config.status and config.log files from the Phobos build directory as well as your OS/CPU information. The PThread semaphores are (would be) a fallback semaphore implementation using pthreads if the target had no recognizable semaphores (e.g., standard POSIX IPC semaphores.) I have not actually written this yet.. David Stephan Wienczny wrote:David Friedman wrote:Try unsetting the 'CC' and 'CXX' environment variables before running configure. Phobos should be built with the same version of gcc/g++/gdc.
After unsetting 'CC' and 'CXX' boehm-gc could be configured, but another error occoured when compiling thread.d. In line 645 is 'Semaphore' undefined. I think that something in gcc.threadsem.d is wrong. gdc was configure with --enable-threads=posix. What is the differnece between POSIX semaphores and PThread (Posix Thread) semaphores? Could it be a problem that I'm using nptl (Native Posix Threading Library) which is build into glibc?
Apr 26 2004
David Friedman wrote:It seems like the conifgure script is not setting up the sempahore implementation. GDC/Phobos does not use the --enable-threads option yet, so that shouldn't be causing any problems. Please send me the config.status and config.log files from the Phobos build directory as well as your OS/CPU information. The PThread semaphores are (would be) a fallback semaphore implementation using pthreads if the target had no recognizable semaphores (e.g., standard POSIX IPC semaphores.) I have not actually written this yet.. David
I found my mistake... I'm writing a new ebuild for the f release and reused the one I wrode for e. One reference to the filename was wrong and I installed e ;-) Now I've got another ebuild related problem: I compiled an installed using ./configure --prefix=/usr gmake My installation procedure looks like this. ${S} is the phobos directory and ${D} a virtual root. dolib copy the file to /usr/lib and dodir makes a directory. Is there something missing? My gdc does not find object.d although it is in /usr/include/d for file in `find | grep "\.o"` do rm $file; done dolib.a ${S}/libphobos.a dolib ${S}/libphobos.spec dodir /usr/include/d/ cp -f *.d phobos-ver-syms ${D}/usr/include/d/ cp -Rf etc gcc internal std ${D}/usr/include/d/
Apr 26 2004
Stephan Wienczny wrote:David Friedman wrote:It seems like the conifgure script is not setting up the sempahore implementation. GDC/Phobos does not use the --enable-threads option yet, so that shouldn't be causing any problems. Please send me the config.status and config.log files from the Phobos build directory as well as your OS/CPU information. The PThread semaphores are (would be) a fallback semaphore implementation using pthreads if the target had no recognizable semaphores (e.g., standard POSIX IPC semaphores.) I have not actually written this yet.. David
I found my mistake... I'm writing a new ebuild for the f release and reused the one I wrode for e. One reference to the filename was wrong and I installed e ;-) Now I've got another ebuild related problem: I compiled an installed using ./configure --prefix=/usr gmake My installation procedure looks like this. ${S} is the phobos directory and ${D} a virtual root. dolib copy the file to /usr/lib and dodir makes a directory. Is there something missing? My gdc does not find object.d although it is in /usr/include/d for file in `find | grep "\.o"` do rm $file; done dolib.a ${S}/libphobos.a dolib ${S}/libphobos.spec dodir /usr/include/d/ cp -f *.d phobos-ver-syms ${D}/usr/include/d/ cp -Rf etc gcc internal std ${D}/usr/include/d/
If object.d really is being installed in /usr/include/d, the only thing I can think of is that gdc itself was configured with a different prefix. I'm assuming that this ebuild uses source-directory == build-directory. Otherwise, it would be miss some .d files, but that wouldn't explain the object.d error message.
Apr 26 2004
Do you have the Java package for gcc? I should have mentioned in the post that it is required now. When the package is extracted in the gcc directory, the link should point to <srcdir>/boehm-gc.
Yes, I forgot, sorry. Thanks for your fixing bugs. By the way, I built PARSEC47 for MacOSX with gdc-r1e. It works really great! (http://my.vector.co.jp/servlet/System.FileDownload/download/http/0/325900/pack/mac/game/action/shoot/p47_0_2.dmg) PARSEC47 is ABA games' exiciting game. (http://www.asahi-net.or.jp/~cs8k-cyu/windows/p47_e.html)
Apr 24 2004
Hi, I found small bugs.
'd/phobos/Makefile.in' is a little inconvenience for creating
libphobosnm.a. I think following patch will work:
--- Makefile.in.orig 2004-04-24 00:27:46.000000000 +0900
+++ Makefile.in 2004-04-24 00:28:09.000000000 +0900
-142,7 +142,7
$(RANLIB) $
internal/dnomain2.o: internal/dmain2.d
- $(DMD) -o $ $(DFLAGS) -fversion=NoPhobosMain -I internal/gc -c $<
+ $(DMD) -o $ $(DFLAGS) -fversion=NoPhobosMain -I $(srcdir) -I
internal/gc -c $<
libphobosnm.a: $(GCC_OBJS) $(INIT_NOMAIN_OBJ) $(MAIN_OBJS) $(ZLIB_OBJS)
$(GC_OBJS) $(RECLS_OBJS) $(D_EXTRA_OBJS)
$(AR) -r $ $(GCC_OBJS) $(INIT_NOMAIN_OBJ) $(MAIN_OBJS) $(ZLIB_OBJS)
$(GC_OBJS) $(RECLS_OBJS) $(D_EXTRA_OBJS)
And boolean assoc array's bug:
void bug() {
bool[int] bi;
bi[1] = true; // compiler crash (on Linux, MacOSX).
}
Error message:
bug_bool.d: In function `bug':
bug_bool.d:0: internal compiler error: in arrayElemRef, at d/d-codegen.cc:1599
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Apr 24 2004
I think std.file.listdir does not work. Following patch will fix.
--- dirent.d~ 2004-04-27 17:31:58.000000000 +0900
+++ dirent.d 2004-04-27 17:33:30.000000000 +0900
-24,5 +24,9
char[] readdirD(DIR * dir)
{
- return toString(readdir(dir).d_name);
+ dirent* ent = readdir(dir);
+ if (ent)
+ return toString(ent.d_name);
+ else
+ return null;
}
Apr 27 2004
I took snapshot 2004-04-27 and tried to build it on cygwin. It's almost working except for some references to '../root/mem.h' which it cannot find. Resolution was to change it to 'mem.h' instead. The #ifdef _WIN32 around those did not work "David Friedman" <d3rdclsmail earthlink.net> wrote in message news:c6a7qv$22bn$2 digitaldaemon.com...Phew! The web page has been updated with a new release. Major highlights: * Reported crashes have been fixed * Update to 0.82 * Compiler no longer requires long double floating point routines * Included parts of the Boehm garbage collector to get the stack and data extents. The compiler and library now build on Cygwin and FreeBSD. Other Unix-like environments should work too. David
May 18 2004
Hi David, Is there a plan to bring GDC up-to-date with the current dmd? Are you waiting for a stable v1.0 release? What's the scoop? Nice work, BTW "David Friedman" <d3rdclsmail earthlink.net> wrote in message news:c6a7qv$22bn$2 digitaldaemon.com...Phew! The web page has been updated with a new release. Major highlights: * Reported crashes have been fixed * Update to 0.82 * Compiler no longer requires long double floating point routines * Included parts of the Boehm garbage collector to get the stack and data extents. The compiler and library now build on Cygwin and FreeBSD. Other Unix-like environments should work too. David
Jul 13 2004
Kris, Not waiting, I just have not been able to spend much time on GDC for the past month or so. There will be a new release soon, however. David Kris wrote:Hi David, Is there a plan to bring GDC up-to-date with the current dmd? Are you waiting for a stable v1.0 release? What's the scoop? Nice work, BTW "David Friedman" <d3rdclsmail earthlink.net> wrote in message news:c6a7qv$22bn$2 digitaldaemon.com...Phew! The web page has been updated with a new release. Major highlights: * Reported crashes have been fixed * Update to 0.82 * Compiler no longer requires long double floating point routines * Included parts of the Boehm garbage collector to get the stack and data extents. The compiler and library now build on Cygwin and FreeBSD. Other Unix-like environments should work too. David
Jul 15 2004
I don't know, how the process of incorporating new language into gcc works, but were there any talks with gcc guys about that (incorporating gdc into gcc)? Or there always will be a need to patch gcc? Kuba David Friedman wrote:Kris, Not waiting, I just have not been able to spend much time on GDC for the past month or so. There will be a new release soon, however. David Kris wrote:Hi David, Is there a plan to bring GDC up-to-date with the current dmd? Are you waiting for a stable v1.0 release? What's the scoop? Nice work, BTW "David Friedman" <d3rdclsmail earthlink.net> wrote in message news:c6a7qv$22bn$2 digitaldaemon.com...Phew! The web page has been updated with a new release. Major highlights: * Reported crashes have been fixed * Update to 0.82 * Compiler no longer requires long double floating point routines * Included parts of the Boehm garbage collector to get the stack and data extents. The compiler and library now build on Cygwin and FreeBSD. Other Unix-like environments should work too. David
Jul 23 2004









Lws <eluusive sbcglobal.net> 