View mode: basic / threaded / horizontal-split · Log in · Help
May 04, 2004
version not working with extern(Windows) on linux
I am porting a few C header files to D, and I'm finding it difficult to get the
versioning working.

specifically, I want to be able to use the same .d file for both windows and
linux

extern (C) {
extern (Windows) {
export void test ();
}
}
this works in windows, and in linux--but it relies on the fact that
extern(Windows) does NOT do anything
a more portable way does NOT work
extern(C) {
export version(Windows){extern (Windows)} void test();
}
the above fails to link in windows though both work in linux
this is using gdc in linux and dmc in windows

any suggestions as to how to get the version to work with the extern (Windows)
command...I want to share a header between the two OS's for ease of use
May 04, 2004
Re: version not working with extern(Windows) on linux
Why use extern (Windows) at all in portable code?

<hellcatv@hotmail.com> wrote in message
news:c77jqd$29em$1@digitaldaemon.com...
> I am porting a few C header files to D, and I'm finding it difficult to
get the
> versioning working.
>
> specifically, I want to be able to use the same .d file for both windows
and
> linux
>
> extern (C) {
> extern (Windows) {
> export void test ();
> }
> }
> this works in windows, and in linux--but it relies on the fact that
> extern(Windows) does NOT do anything
> a more portable way does NOT work
> extern(C) {
> export version(Windows){extern (Windows)} void test();
> }
> the above fails to link in windows though both work in linux
> this is using gdc in linux and dmc in windows
>
> any suggestions as to how to get the version to work with the extern
(Windows)
> command...I want to share a header between the two OS's for ease of use
>
>
May 04, 2004
Re: version not working with extern(Windows) on linux
I'm trying to link in opengl32.dll and glut32.dll
so I need to create a gl.d (to replace gl.h) and glut.d (to replace 
glut.h), preferably a gl.d that I can share between linux and windows.

Right now it works, but I am using extern(Windows){ at the top

I could fool the linker by making a specially hacked glut32.def and 
opengl32.def file to alias the extern(C) type exports to the ones 
defined in the dll--is this the preferred method? It seems like changing 
the calling convention to keep cross-platform is not necessarily a good idea

ideally we COULD have a single header file that would serve both linux 
.so and windows .dll's much like gl.h does today
i.e. I think version should also be able to #ifdef out extern(Windows)

Walter wrote:
> Why use extern (Windows) at all in portable code?
> 
> <hellcatv@hotmail.com> wrote in message
> news:c77jqd$29em$1@digitaldaemon.com...
> 
>>I am porting a few C header files to D, and I'm finding it difficult to
> 
> get the
> 
>>versioning working.
>>
>>specifically, I want to be able to use the same .d file for both windows
> 
> and
> 
>>linux
>>
>>extern (C) {
>>extern (Windows) {
>>export void test ();
>>}
>>}
>>this works in windows, and in linux--but it relies on the fact that
>>extern(Windows) does NOT do anything
>>a more portable way does NOT work
>>extern(C) {
>>export version(Windows){extern (Windows)} void test();
>>}
>>the above fails to link in windows though both work in linux
>>this is using gdc in linux and dmc in windows
>>
>>any suggestions as to how to get the version to work with the extern
> 
> (Windows)
> 
>>command...I want to share a header between the two OS's for ease of use
>>
>>
> 
> 
>
May 04, 2004
Re: version not working with extern(Windows) on linux
Daniel Horn wrote:
> I'm trying to link in opengl32.dll and glut32.dll
> so I need to create a gl.d (to replace gl.h) and glut.d (to replace 
> glut.h), preferably a gl.d that I can share between linux and windows.
> 
> Right now it works, but I am using extern(Windows){ at the top
> 
> I could fool the linker by making a specially hacked glut32.def and 
> opengl32.def file to alias the extern(C) type exports to the ones 
> defined in the dll--is this the preferred method? It seems like changing 
> the calling convention to keep cross-platform is not necessarily a good 
> idea
> 
> ideally we COULD have a single header file that would serve both linux 
> .so and windows .dll's much like gl.h does today
> i.e. I think version should also be able to #ifdef out extern(Windows)

This should get you where you want to be:

version (Win32) {
    extern (Windows):
} else {
    extern (C):
}

void glThingie(...); // this will be extern (Windows) on win32, else
                     // extern(C)
void glOtherThingie(...);
// et cetera

 -- andy
May 04, 2004
Re: version not working with extern(Windows) on linux
"Daniel Horn" <hellcatv@hotmail.com> wrote in message
news:c78n8f$tgg$1@digitaldaemon.com...
> I'm trying to link in opengl32.dll and glut32.dll
> so I need to create a gl.d (to replace gl.h) and glut.d (to replace
> glut.h), preferably a gl.d that I can share between linux and windows.
>
> Right now it works, but I am using extern(Windows){ at the top
>
> I could fool the linker by making a specially hacked glut32.def and
> opengl32.def file to alias the extern(C) type exports to the ones
> defined in the dll--is this the preferred method?

That will not work, because the linker cannot change the calling convention.

> It seems like changing
> the calling convention to keep cross-platform is not necessarily a good
idea
> ideally we COULD have a single header file that would serve both linux
> .so and windows .dll's much like gl.h does today
> i.e. I think version should also be able to #ifdef out extern(Windows)

I think the easiest way to make this work is just cut and paste the
declarations:

version (Windows)
{
   extern (Windows):
       declarations...
}
else
{
   extern (C)
       declarations...
}
May 04, 2004
Re: version not working with extern(Windows) on linux
Walter wrote:
 > I think the easiest way to make this work is just cut and paste the
> declarations:
> 
> version (Windows)
> {
>     extern (Windows):
>         declarations...
> }
> else
> {
>     extern (C)
>         declarations...
> }
> 

I think copying code is the worst thing you could do. This kind of stuff 
can quickly become a maintenance nightmare. The whole point of 
conditional compilation is to have the same piece of code work in 
different environments, so that you will NOT have to manually copy all 
changes to all targets (and inevitably forget some).

Otherwise you could just as well create different source files for each 
version and only compile the one you want.

Just an idea, but does/could alias work for such situations? Like:

version(Windows)
	alias extern(Windows) extern(MyConvention);
else
	alias extern(C) extern(MyConvention);

extern(MyConvention):
	...


However, my guess is that version will need to become more powerful 
anyway. There is a lot of conditional compilation stuff that just isn't 
possible in D right now. Especially boolean expressions among version 
parameters (i.e. version( a || b && !c) are a must have, IMHO.


Hauke
May 05, 2004
Re: version not working with extern(Windows) on linux
pasting the function definitions twice?? that's so much bloat!
that means double the work every time a new EXT extension gets 
added...sure I could write a script--but it's messy and it would be nice 
if a mechanism existed to automate the procedure

or how about defining that extern(Windows) does something "right" in 
linux :-) (it seems to work properly with extern(Windows) for both linux 
and windows..but given that it's not in the spec I hesitate to ship 
something with it)

Walter wrote:
> "Daniel Horn" <hellcatv@hotmail.com> wrote in message
> news:c78n8f$tgg$1@digitaldaemon.com...
> 
>>I'm trying to link in opengl32.dll and glut32.dll
>>so I need to create a gl.d (to replace gl.h) and glut.d (to replace
>>glut.h), preferably a gl.d that I can share between linux and windows.
>>
>>Right now it works, but I am using extern(Windows){ at the top
>>
>>I could fool the linker by making a specially hacked glut32.def and
>>opengl32.def file to alias the extern(C) type exports to the ones
>>defined in the dll--is this the preferred method?
> 
> 
> That will not work, because the linker cannot change the calling convention.
> 
> 
>>It seems like changing
>>the calling convention to keep cross-platform is not necessarily a good
> 
> idea
> 
>>ideally we COULD have a single header file that would serve both linux
>>.so and windows .dll's much like gl.h does today
>>i.e. I think version should also be able to #ifdef out extern(Windows)
> 
> 
> I think the easiest way to make this work is just cut and paste the
> declarations:
> 
> version (Windows)
> {
>     extern (Windows):
>         declarations...
> }
> else
> {
>     extern (C)
>         declarations...
> }
> 
>
May 05, 2004
Re: version not working with extern(Windows) on linux
Daniel Horn wrote:

> I'm trying to link in opengl32.dll and glut32.dll
> so I need to create a gl.d (to replace gl.h) and glut.d (to replace 
> glut.h), preferably a gl.d that I can share between linux and windows.
> 
> Right now it works, but I am using extern(Windows){ at the top
> 
> I could fool the linker by making a specially hacked glut32.def and 
> opengl32.def file to alias the extern(C) type exports to the ones 
> defined in the dll--is this the preferred method? It seems like changing 
> the calling convention to keep cross-platform is not necessarily a good 
> idea
> 
> ideally we COULD have a single header file that would serve both linux 
> .so and windows .dll's much like gl.h does today
> i.e. I think version should also be able to #ifdef out extern(Windows)

For what it's worth, I am at this very moment working on some openGL 
modules which load the library dynamically. There are separate modules 
for each OGL version (gl11.d, ..., gl15.d), and a primary gl.d which 
publicly imports the other modules and handles the loading. Where a full 
implementation of a version is not implemented (via extensions or 
otherwise), the supported subset is loaded as extensions. I should be 
finished very soon and will post the modules on the NG when I am.
May 05, 2004
Re: version not working with extern(Windows) on linux
wow that's really cool
I was working on the same thing
I was only going to do version 1.1 and then force the user to dynamically grab
teh extension functions with the glGetProcAddress (i wrote a wrapper around the
lin and win versions)

but having the program dynamically load the proper extensions as needed (and
perhaps throw an exception in the event of a missing extension) would probably
be better...
I can 
To see my work-in-progress check out
http://graphics.stanford.edu/~danielrh/d/

it compiles and runs a glut test app on both win and lin :-)
--Daniel

PS:I haven't tried to call an extension function yet
In article <c79me1$2cvi$1@digitaldaemon.com>, mike parker says...
>
>Daniel Horn wrote:
>
>> I'm trying to link in opengl32.dll and glut32.dll
>> so I need to create a gl.d (to replace gl.h) and glut.d (to replace 
>> glut.h), preferably a gl.d that I can share between linux and windows.
>> 
>> Right now it works, but I am using extern(Windows){ at the top
>> 
>> I could fool the linker by making a specially hacked glut32.def and 
>> opengl32.def file to alias the extern(C) type exports to the ones 
>> defined in the dll--is this the preferred method? It seems like changing 
>> the calling convention to keep cross-platform is not necessarily a good 
>> idea
>> 
>> ideally we COULD have a single header file that would serve both linux 
>> .so and windows .dll's much like gl.h does today
>> i.e. I think version should also be able to #ifdef out extern(Windows)
>
>For what it's worth, I am at this very moment working on some openGL 
>modules which load the library dynamically. There are separate modules 
>for each OGL version (gl11.d, ..., gl15.d), and a primary gl.d which 
>publicly imports the other modules and handles the loading. Where a full 
>implementation of a version is not implemented (via extensions or 
>otherwise), the supported subset is loaded as extensions. I should be 
>finished very soon and will post the modules on the NG when I am.
May 05, 2004
Re: version not working with extern(Windows) on linux
hellcatv@hotmail.com wrote:

>wow that's really cool
>I was working on the same thing
>I was only going to do version 1.1 and then force the user to dynamically grab
>teh extension functions with the glGetProcAddress (i wrote a wrapper around the
>lin and win versions)
>
>but having the program dynamically load the proper extensions as needed (and
>perhaps throw an exception in the event of a missing extension) would probably
>be better...
>I can 
>To see my work-in-progress check out
>http://graphics.stanford.edu/~danielrh/d/
>  
>

If your talking about openGL extensions.  I ported GLee which supports 
over 300 opengl extensions.

-- 
-Anderson: http://badmama.com.au/~anderson/
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home