Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
November 04, 2002 Local struct problems, among others | ||||
---|---|---|---|---|
| ||||
I am trying to use Digital Mars for some game development. I had hoped to use the "Open Dynamics Engine v0.03" to provide physics. ODE only supports MSVC and CygWin as Win32 compilers, but I thought I might be able to fake it with some smallish modifications and the use of the DigitalMars CL.EXE command line translator. After fixing one or two #ifdef areas that misunderstood the compiler environment, the next error I got could be tracked down to (eventually) the following kind of code construct. The names have been changed, just 'coz I felt like it... //////////////////// struct Thing : public RootOfAllEvil { struct LocalThing { void * SomeStuff; }; LocalThing * Whoops; }; Thing::LocalThing * __GlobalWhoops; ////////////////////// At this point, anyone who attempts to use __GlobalWhoops as a Thing::LocalThing* will be informed either than an explicit cast is needed, or that __GlobalWhoops has already been defined as something else. The gist of the problem is that the compiler seems to think that __GlobalWhoops is of type Thing*, not of type Thing::LocalThing*. I have played with ordering and changing names, neither of which has any effect. Concerned that I might not have the newest compiler, I checked the version of dmc, and was told 8.29n. Which is odd, since I had applied the 8.30 CD patch. To be safe, I downloaded the compiler-only 8.30c zip file and applied that. The version is still reported as 8.29n. I finally gave up and moved all (there were several) local struct definitions out of dxJoint (the class upon which the contrived Thing was based), and then went around removing all of the scope resolution operators. This poluted the global name space, but at least it allowed the code to compile. Now that the code compiles, I have a new problem. While CL.EXE was able to translate the compiler switches, I don't have anything to translate the linker and librarian switches. When the make file attempts to bundle things up into a library, it chokes a great deal, confusing parts of the filespec as if it thought they were switches. For example: Warning: Unknown switch 'src' in command line, ignored. Warning: Unknown switch 'fastldlt' in command line, ignored. So my three problems are: 1. Does DMC have a problem with local structs (structs within structs)? 2. Is the newest DMC supposed to report 8.29n? 3. How can I easily translate command line switches designed for MSVC librarian to DMC librarian? Any help would be greatly appreciated. I would prefer to avoid going to CygWin, due to past painful experiences. Thanks, Mac |
November 04, 2002 Re: Local struct problems, among others | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mac Reiter | "Mac Reiter" <Mac_member@pathlink.com> wrote in message news:aq4kt0$v7i$1@digitaldaemon.com... > I am trying to use Digital Mars for some game development. I had hoped to use > the "Open Dynamics Engine v0.03" to provide physics. ODE only supports MSVC and > CygWin as Win32 compilers, but I thought I might be able to fake it with some > smallish modifications and the use of the DigitalMars CL.EXE command line translator. > > After fixing one or two #ifdef areas that misunderstood the compiler environment, the next error I got could be tracked down to (eventually) the > following kind of code construct. The names have been changed, just 'coz I felt > like it... > > //////////////////// > struct Thing : public RootOfAllEvil > { > struct LocalThing > { > void * SomeStuff; > }; > > LocalThing * Whoops; > }; > > Thing::LocalThing * __GlobalWhoops; > ////////////////////// > > At this point, anyone who attempts to use __GlobalWhoops as a Thing::LocalThing* > will be informed either than an explicit cast is needed, or that __GlobalWhoops > has already been defined as something else. The gist of the problem is that the > compiler seems to think that __GlobalWhoops is of type Thing*, not of type Thing::LocalThing*. I have played with ordering and changing names, neither of > which has any effect. > > Concerned that I might not have the newest compiler, I checked the version of > dmc, and was told 8.29n. Which is odd, since I had applied the 8.30 CD patch. > To be safe, I downloaded the compiler-only 8.30c zip file and applied that. The > version is still reported as 8.29n. > > I finally gave up and moved all (there were several) local struct definitions > out of dxJoint (the class upon which the contrived Thing was based), and then > went around removing all of the scope resolution operators. This poluted the > global name space, but at least it allowed the code to compile. > > Now that the code compiles, I have a new problem. While CL.EXE was able to > translate the compiler switches, I don't have anything to translate the linker > and librarian switches. When the make file attempts to bundle things up into a > library, it chokes a great deal, confusing parts of the filespec as if it thought they were switches. For example: > > Warning: Unknown switch 'src' in command line, ignored. Warning: Unknown switch 'fastldlt' in command line, ignored. > > So my three problems are: > 1. Does DMC have a problem with local structs (structs within structs)? Not that I know of. I'll check out your example. > 2. Is the newest DMC supposed to report 8.29n? Try just typing scppn and see what it says. > 3. How can I easily translate command line switches designed for MSVC librarian > to DMC librarian? It used to match, Microsoft changed theirs :-( Anyway, post the command lines and we'll have a look. > > Any help would be greatly appreciated. I would prefer to avoid going to CygWin, > due to past painful experiences. > > Thanks, > Mac > > |
November 04, 2002 Re: Local struct problems, among others | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | >> So my three problems are: >> 1. Does DMC have a problem with local structs (structs within structs)? > >Not that I know of. I'll check out your example. If my example doesn't kick in, the actual code base I was working with was the 0.03 Open Dynamics Engine tarball. I used the msvc configuration, and just removed compiler command line arguments that CL.EXE didn't recognize (they were optimization style flags, not functionality flags). I would try to pair it down, but if the example I gave doesn't trigger it, then I suspect it is something bizarre about the context. A Google search for Open Dynamics Engine will find the site pretty quickly. >> 2. Is the newest DMC supposed to report 8.29n? > >Try just typing scppn and see what it says. I'll try it out over lunch, while I'm home. >> 3. How can I easily translate command line switches designed for MSVC >librarian >> to DMC librarian? > >It used to match, Microsoft changed theirs :-( Anyway, post the command lines and we'll have a look. OK. Thank you! Mac |
November 04, 2002 Re: Local struct problems, among others | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | >> 2. Is the newest DMC supposed to report 8.29n? > >Try just typing scppn and see what it says. OK, I got 8.30.11 from that. >> 3. How can I easily translate command line switches designed for MSVC >librarian >> to DMC librarian? > >It used to match, Microsoft changed theirs :-( Anyway, post the command lines and we'll have a look. Here's the chunk of Makefile that is being used. I think it is the AR line that is giving me grief, but anyone with more MSVC and/or Make command line experience will probably understand better. I'm a bit of an IDE weenie myself... -------------------- WINDOWS=1 THIS_DIR= DEL_CMD=tools\rm CC=cl /nologo /DWIN32 /DMSVC OBJ=.obj C_FLAGS=/c /GR- /GX- /W3 C_INC=/ID:/Programming/ode-0.03/ C_OUT=/Fo C_EXEOUT=/Fe C_DEF=/D C_OPT=/O AR=lib /nologo /OUT: RANLIB= LIB_PREFIX= LIB_SUFFIX=.lib LINK_OPENGL=Comctl32.lib kernel32.lib user32.lib gdi32.lib OpenGL32.lib Glu32.lib LINK_MATH= RC_RULE=rc /r /fo$@ $< ifeq ($(BUILD),release) OPT=2 endif ifeq ($(BUILD),debug) OPT=d endif ------------------- Thanks again! Mac |
November 05, 2002 Re: Local struct problems, among others | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mac Reiter | I think all you need to do for the librarian is: lib -c libraryname objfiles... For the linker, just list the .lib files: link obj+obj+obj,exe,map,Comctl32+kernel32+user32+gdi32+OpenGL32+Glu32.lib,def,re s; "Mac Reiter" <Mac_member@pathlink.com> wrote in message news:aq6f2l$2s4h$1@digitaldaemon.com... > >> 2. Is the newest DMC supposed to report 8.29n? > > > >Try just typing scppn and see what it says. > > OK, I got 8.30.11 from that. > > >> 3. How can I easily translate command line switches designed for MSVC > >librarian > >> to DMC librarian? > > > >It used to match, Microsoft changed theirs :-( Anyway, post the command lines and we'll have a look. > > Here's the chunk of Makefile that is being used. I think it is the AR line that > is giving me grief, but anyone with more MSVC and/or Make command line experience will probably understand better. I'm a bit of an IDE weenie myself... > > -------------------- > WINDOWS=1 > THIS_DIR= > DEL_CMD=tools\rm > CC=cl /nologo /DWIN32 /DMSVC > OBJ=.obj > C_FLAGS=/c /GR- /GX- /W3 > C_INC=/ID:/Programming/ode-0.03/ > C_OUT=/Fo > C_EXEOUT=/Fe > C_DEF=/D > C_OPT=/O > AR=lib /nologo /OUT: > RANLIB= > LIB_PREFIX= > LIB_SUFFIX=.lib > LINK_OPENGL=Comctl32.lib kernel32.lib user32.lib gdi32.lib OpenGL32.lib > Glu32.lib > LINK_MATH= > RC_RULE=rc /r /fo$@ $< > > ifeq ($(BUILD),release) > OPT=2 > endif > > ifeq ($(BUILD),debug) > OPT=d > endif > ------------------- > > Thanks again! > Mac > > |
Copyright © 1999-2021 by the D Language Foundation