Hi!

I'm implementing condition variables (as discussed on .D) for GDC but am having a problems with phobos.

For this I've ported (Linux Threads) pthreads.h to std.c.linux.pthreads, but when I try to add struct timespec to linux.d, I get

./../../gcc-3.3.6/libphobos/std/c/linux/pthreads.d:276: identifier 'timespec' is not defined

This seems odd to me, since struct timeval four lines up works in other modules.

Second, when compiling a test for the condvars, I end up with

(.data+0x30): undefined reference to `_ModuleInfo_3std1c5linux5linux'

in ld. Some research tells me the std/c/linux stuff isn't even linked into libgphobos.a. What's the rationale for this?

/Tommie

Tommie Gannert wrote:

> Second, when compiling a test for the condvars, I end up with
> 
> (.data+0x30): undefined reference to `_ModuleInfo_3std1c5linux5linux'
> 
> in ld. Some research tells me the std/c/linux stuff isn't even linked into
> libgphobos.a. What's the rationale for this?

Most of DMD's std.c.linux.linux stuff is handled in GDC std.c.unix.unix.
("linux" isn't portable) http://dsource.org/forums/viewtopic.php?t=681

I was under the impression GDC still featured the old stuff, though ?
(but since I've running it on Mac for a while, I wouldn't know now)


Digital Mars hasn't even added the *versions* to DMD, as far as I know.
So getting the 2 compilers to use the same structure here is far away...

http://www.digitalmars.com/d/version.html ("Windows"/"linux" only)
http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Version (others)

--anders

Anders F Björklund wrote:
> Tommie Gannert wrote:
> 
>> Second, when compiling a test for the condvars, I end up with
>>
>> (.data+0x30): undefined reference to `_ModuleInfo_3std1c5linux5linux'
>>
>> in ld. Some research tells me the std/c/linux stuff isn't even linked into
>> libgphobos.a. What's the rationale for this?
> 
> 
> Most of DMD's std.c.linux.linux stuff is handled in GDC std.c.unix.unix.
> ("linux" isn't portable) http://dsource.org/forums/viewtopic.php?t=681
> 
> I was under the impression GDC still featured the old stuff, though ?
> (but since I've running it on Mac for a while, I wouldn't know now)
> 
> 
> Digital Mars hasn't even added the *versions* to DMD, as far as I know.
> So getting the 2 compilers to use the same structure here is far away...
> 
> http://www.digitalmars.com/d/version.html ("Windows"/"linux" only)
> http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Version (others)
> 
> --anders

Indeed, std.c.unix is the preferred way to do things for GDC. I intended to support std.c.linux for compatibility, but never made the necessary changes.

David

In article <dmsb3e$6g5$1@digitaldaemon.com>, David Friedman says...
>
>> --anders
>
>Indeed, std.c.unix is the preferred way to do things for GDC. I intended to support std.c.linux for compatibility, but never made the necessary changes.
>
>David

Thanks, both of you. I changed it to std.c.unix since it had the timespec... Now it works fine. The question now is where I should put the pthreads module. It is a common *nix interface, so it might be a good idea to put it in unix, right?

I could probably make a nice generator for that one to, but is it worth it? I definately need more than the pthread types generated in unix.

Tommie Gannert wrote:
> In article <dmsb3e$6g5$1@digitaldaemon.com>, David Friedman says...
> 
>>>--anders
>>
>>Indeed, std.c.unix is the preferred way to do things for GDC. I intended to support std.c.linux for compatibility, but never made the necessary changes.
>>
>>David
> 
> 
> Thanks, both of you. I changed it to std.c.unix since it had the timespec... Now
> it works fine. The question now is where I should put the pthreads module. It is
> a common *nix interface, so it might be a good idea to put it in unix, right?
> 
> I could probably make a nice generator for that one to, but is it worth it?
> I definately need more than the pthread types generated in unix.
> 
> 

If you need more pthread types and functions declared in std.unix.unix, I can add them (might as well make it standard).  The GDC Phobos configuration script already generates types (see d/phobos/config/gen_unix.c in the distribution.)  So far, I have been able to write the function declaration manually (d/phobos/config/unix-mid.)

David Friedman wrote:

> Indeed, std.c.unix is the preferred way to do things for GDC. I intended to support std.c.linux for compatibility, but [...]

Seems about PAR for the course...

One standard way (gdc, unix), and one compat way (gdmd, linux) ?


Speaking of that, the home page still says "dmd": (and not gdmd)

"The compiler driver is named 'gdc' and accepts the standard GCC options.  There is also a script named 'dmd' which has the same interface as the Digital Mars dmd."

--anders

Anders F Björklund wrote:
> David Friedman wrote:
> 
>> Indeed, std.c.unix is the preferred way to do things for GDC. I intended to support std.c.linux for compatibility, but [...]
> 
> 
> Seems about PAR for the course...
> 
> One standard way (gdc, unix), and one compat way (gdmd, linux) ?

Probably unavoidable with bridging two different compiler systems. Hopefully, we can smooth out some of the rough edges. On the GCC mailing list, they're discussing merging LLVM and GCC.  Can't imagine what that would be like...


> 
> 
> Speaking of that, the home page still says "dmd": (and not gdmd)
> 
> "The compiler driver is named 'gdc' and accepts the standard GCC options.  There is also a script named 'dmd' which has the same interface as the Digital Mars dmd."
> 
> --anders


Fixed -- thanks.

David Friedman wrote:

>> One standard way (gdc, unix), and one compat way (gdmd, linux) ?
> 
> Probably unavoidable with bridging two different compiler systems. Hopefully, we can smooth out some of the rough edges. [...]

Some things are probably inherited from GCC and DMC, respectively...
(and seem to ultimately reflect different environments, Win vs. Unix)

But other things, like "version(Unix)" and "std.c.unix.unix" should
be easier to add to the D specs - along with std.stdarg.va_list, etc ?


Then again, I can't claim to understand all of the priorities in D,
like adding std.recls and std.openrj before std.sdl and std.opengl.

And as Walter only knows about DMD, I'll just help out where I can:
i.e. with GDC (under the GPL) and on the Wiki4D (under the FDL)...


I know that others are making similar efforts, like http://dsource.org
Coordinating all these D efforts into one "body" would be a GOOD thing ?

Getting rid of some ancient old stuff, like http:/opend.org, would too -
including the even older http://sourceforge.net/projects/brightd project

But I'm not holding my breath.
--anders