> 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)

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.

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?

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?
> 

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/

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.

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;
 }

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
> 

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
>

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
>>
> 
> 
>