Jump to page: 1 2
Thread overview
help: i don't understand these errors :(
Aug 07, 2004
clayasaurus
Aug 07, 2004
Deja Augustine
Aug 07, 2004
J C Calvarese
Aug 07, 2004
clayasaurus
Aug 07, 2004
J C Calvarese
Aug 07, 2004
clayasaurus
Aug 08, 2004
J C Calvarese
Aug 08, 2004
clayasaurus
Aug 08, 2004
J C Calvarese
Aug 08, 2004
clayasaurus
Aug 07, 2004
Ben Hinkle
Aug 07, 2004
clayasaurus
August 07, 2004
So, I've been trying to get my program to compile under windows with makefiles and I get some strange errors...

dmd src\claytek\engine.d  src\claytek\log.d  src\claytek\window.d src\claytek\input.d  src\claytek\timers.d -c -v -debug -Isrc -odobj\claytek
parse     engine
parse     log
parse     window
parse     input
parse     timers
semantic  engine
src\claytek\engine.d(29): module input is in multiply defined
src\claytek\input.d(18): module window is in multiply defined
src\claytek\window.d(26): module log is in multiply defined
src\claytek\math\vector.d(26): import std conflicts with gl.std at src\derelict\opengl\gl.d(27)
src\claytek\math\vector.d(26): import std conflicts with gl.std at src\derelict\opengl\gl.d(27)
src\claytek\engine.d(34): module timers is in multiply defined
semantic  log
semantic  window
semantic  input
semantic  timers

--- errorlevel 1


one of them is "module is in multiply defined." Does that mean that there is more than one import of the same file in the same file? If so, what is wrong with that? I know in c++ you had to do
#ifndef HEADER
#define HEADER
but I thought D does away with all that. It works in linux.

Another error I don't understand is the "std conflicts with gl.std at gl.d (27)

in gl.d on line 27 is an import for std.loader, which seeminly conlicts with std.math in vector.d.

why do these two conflict? they are from the same std. library.
Can someone help me please? thx.














August 07, 2004
clayasaurus wrote:
> So, I've been trying to get my program to compile under windows with makefiles and I get some strange errors...
> 
<snip>
> 
> one of them is "module is in multiply defined." Does that mean that there is more than one import of the same file in the same file? If so, what is wrong with that? I know in c++ you had to do
> #ifndef HEADER
> #define HEADER
> but I thought D does away with all that. It works in linux.
> 
<snip>

D does symbolic imports.  You should never have to import a module more than once.  One import <module> statement will import all of the symbols  from that module into the global scope of the importing file.

As for the second problem you're having I don't have much to offer by way of help.  Sorry.

-Deja
August 07, 2004
clayasaurus wrote:
> So, I've been trying to get my program to compile under windows with makefiles and I get some strange errors...
> 
> dmd src\claytek\engine.d  src\claytek\log.d  src\claytek\window.d src\claytek\input.d  src\claytek\timers.d -c -v -debug -Isrc -odobj\claytek
> parse     engine
> parse     log
> parse     window
> parse     input
> parse     timers
> semantic  engine
> src\claytek\engine.d(29): module input is in multiply defined
> src\claytek\input.d(18): module window is in multiply defined
> src\claytek\window.d(26): module log is in multiply defined
> src\claytek\math\vector.d(26): import std conflicts with gl.std at src\derelict\opengl\gl.d(27)
> src\claytek\math\vector.d(26): import std conflicts with gl.std at src\derelict\opengl\gl.d(27)
> src\claytek\engine.d(34): module timers is in multiply defined

I seen messages like this in the past, and I believe they indicate flaws in the compiler. The messages always appeared helpful at first glance, but when I looked at the actual code, they appeared non-sensical.

If the offending code is in SVN (or you can upload a .zip that demonstrates the problem), I'd like to play with it trying to come up with a minimal test case for a bug report.

> semantic  log
> semantic  window
> semantic  input
> semantic  timers
> 
> --- errorlevel 1
> 
> 
> one of them is "module is in multiply defined." Does that mean that there is more than one import of the same file in the same file? If so, what is wrong with that? I know in c++ you had to do

I'd guess it means that you have two files with the same module statement, e.g.:

//[file1.d]

module mylib.mypkg.file1.d


//[file2.d]

module mylib.mypkg.file1.d


If this is the case, I've complained about this situation before (and posted a bug report on it). I'm sure Walter has bigger fish to fry, but I hope he gets a chance to improve the error message eventually.

> #ifndef HEADER
> #define HEADER
> but I thought D does away with all that. It works in linux.
> 
> Another error I don't understand is the "std conflicts with gl.std at gl.d (27)

I've seen this before and somehow I figured out how to fix it, but I never understood what caused it.

> 
> in gl.d on line 27 is an import for std.loader, which seeminly conlicts with std.math in vector.d.
> 
> why do these two conflict? they are from the same std. library.
> Can someone help me please? thx.

I'd like to look at the code. I think there's a good bug report in there somewhere.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
August 07, 2004
> src\claytek\engine.d(29): module input is in multiply defined

this typically happens to me when I forget to put
 module claytek.input;
at the top of claytek\input.d

August 07, 2004
Ben Hinkle wrote:
>>src\claytek\engine.d(29): module input is in multiply defined
> 
> 
> this typically happens to me when I forget to put
>  module claytek.input;
> at the top of claytek\input.d
> 

Thanks, that's it for the multiply defined compiler error. It's not that  I forgot, it is just that in dmd linux I can get away with it, and I'd rather not put module claytek.input in case I change the name of my file I don't have to alter any code. Ah well, it looks like windows is enforcing the use of the module keyword :)

Now for the conflicting standard problem...
August 07, 2004
J C Calvarese wrote:

> clayasaurus wrote:
> 
>> So, I've been trying to get my program to compile under windows with makefiles and I get some strange errors...
>>
>> dmd src\claytek\engine.d  src\claytek\log.d  src\claytek\window.d src\claytek\input.d  src\claytek\timers.d -c -v -debug -Isrc -odobj\claytek
>> parse     engine
>> parse     log
>> parse     window
>> parse     input
>> parse     timers
>> semantic  engine
>> src\claytek\engine.d(29): module input is in multiply defined
>> src\claytek\input.d(18): module window is in multiply defined
>> src\claytek\window.d(26): module log is in multiply defined
>> src\claytek\math\vector.d(26): import std conflicts with gl.std at src\derelict\opengl\gl.d(27)
>> src\claytek\math\vector.d(26): import std conflicts with gl.std at src\derelict\opengl\gl.d(27)
>> src\claytek\engine.d(34): module timers is in multiply defined
> 
> 
> I seen messages like this in the past, and I believe they indicate flaws in the compiler. The messages always appeared helpful at first glance, but when I looked at the actual code, they appeared non-sensical.
> 
> If the offending code is in SVN (or you can upload a .zip that demonstrates the problem), I'd like to play with it trying to come up with a minimal test case for a bug report.

svn co http://svn.dsource.org/svn/projects/claytek <-- my svn repository
I just checked in revision 90 to get rid of the multiply defined error a second ago. If I figure out how to fix the other error I'll post here again. Anyway, one you download the code, go into c:\claytek\trunk folder and type 'make claytek' to get the error I'm talking about.

> 
>> semantic  log
>> semantic  window
>> semantic  input
>> semantic  timers
>>
>> --- errorlevel 1
>>
>>
>> one of them is "module is in multiply defined." Does that mean that there is more than one import of the same file in the same file? If so, what is wrong with that? I know in c++ you had to do
> 
> 
> I'd guess it means that you have two files with the same module statement, e.g.:
> 
> //[file1.d]
> 
> module mylib.mypkg.file1.d
> 
> 
> //[file2.d]
> 
> module mylib.mypkg.file1.d
> 
> 
> If this is the case, I've complained about this situation before (and posted a bug report on it). I'm sure Walter has bigger fish to fry, but I hope he gets a chance to improve the error message eventually.
> 
>> #ifndef HEADER
>> #define HEADER
>> but I thought D does away with all that. It works in linux.
>>
>> Another error I don't understand is the "std conflicts with gl.std at gl.d (27)
> 
> 
> I've seen this before and somehow I figured out how to fix it, but I never understood what caused it.
> 
>>
>> in gl.d on line 27 is an import for std.loader, which seeminly conlicts with std.math in vector.d.
>>
>> why do these two conflict? they are from the same std. library.
>> Can someone help me please? thx.
> 
> 
> I'd like to look at the code. I think there's a good bug report in there somewhere.
> 

please, feel free to :)
August 07, 2004
clayasaurus wrote:
> J C Calvarese wrote:
> 
>> clayasaurus wrote:
>>> src\claytek\math\vector.d(26): import std conflicts with gl.std at
>>> src\derelict\opengl\gl.d(27)
>>> src\claytek\math\vector.d(26): import std conflicts with gl.std at
>>> src\derelict\opengl\gl.d(27)
...
> svn co http://svn.dsource.org/svn/projects/claytek <-- my svn repository I just checked in revision 90 to get rid of the multiply defined error a second ago. If I figure out how to fix the other error I'll post here again. Anyway, one you download the code, go into c:\claytek\trunk folder and type 'make claytek' to get the error I'm talking about.

I got the code and found the bug. I think it's basically the same the that I posted a bug report on earlier, but I'm probably going to post it again with a new example.

...
>> I'd like to look at the code. I think there's a good bug report in there somewhere.
>>
> 
> please, feel free to :)

I got it down to 5 files / about 20 lines total (attached). Hopefully, it'll give you a hint about what you need to do to get it to work. I still think it's a compiler bug.

(I'm going to spend a little more time and cut it down to probably 3 files / 10 lines before I post it as a bug.)

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/


August 07, 2004
> J C Calvarese wrote:
> 
> I got the code and found the bug. I think it's basically the same the that I posted a bug report on earlier, but I'm probably going to post it again with a new example.

awesome :)

> J C Calvarese wrote:
> I got it down to 5 files / about 20 lines total (attached). Hopefully, it'll give you a hint about what you need to do to get it to work. I still think it's a compiler bug.
> 
> (I'm going to spend a little more time and cut it down to probably 3 files / 10 lines before I post it as a bug.)
> 

cool. i'll take a look at it.

> 
> ------------------------------------------------------------------------
> 
> dmd claytek_engine.d -c -v -debug -Isrc
> pause
> 
> 
> ------------------------------------------------------------------------
> 
> module claytek_engine; 
> 
> import claytek_geometry_rectangle;
> 
> 
> ------------------------------------------------------------------------
> 
> module claytek_math_vector;
> 
> 
> import std.stream;
> 
> 
> 
> struct Vector {}
> 
> 
> ------------------------------------------------------------------------
> 
> module claytek_geometry_line; 
> 
> import claytek_math_vector;
> import derelict_opengl_gl;
> 
> 
> struct Ray {
> 
> public:
>     Vector start;
> 
>     void write(inout std.stream.File file) {}
> 
> }
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> module claytek_geometry_rectangle; 
> 
> import claytek_geometry_line;
> 
> 
> 
> ------------------------------------------------------------------------
> 
> module derelict_opengl_gl;
> 
> private import std.c.windows.windows;
> 
August 08, 2004
clayasaurus wrote:
>  > J C Calvarese wrote:
> 
>>
>> I got the code and found the bug. I think it's basically the same the that I posted a bug report on earlier, but I'm probably going to post it again with a new example.
> 
> 
> awesome :)
> 
>> J C Calvarese wrote:
>> I got it down to 5 files / about 20 lines total (attached). Hopefully, it'll give you a hint about what you need to do to get it to work. I still think it's a compiler bug.
>>
>> (I'm going to spend a little more time and cut it down to probably 3 files / 10 lines before I post it as a bug.)
>>
> 
> cool. i'll take a look at it.

I just posed the bug report at http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1307


By the way, I think I found a fix for your problem, too. Try these changes:
src\claytek\geometry\line.d (line 89):  void read (inout File file)
src\claytek\geometry\line.d (line 98):  void write(inout File file)


-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
August 08, 2004
J C Calvarese wrote:
> 
> I just posed the bug report at http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1307
> 
> 
> By the way, I think I found a fix for your problem, too. Try these changes:
> src\claytek\geometry\line.d (line 89):  void read (inout File file)
> src\claytek\geometry\line.d (line 98):  void write(inout File file)
> 

Cool, and made those changes and the error went away :)

However, something else I don't understand has cropped up.

dmd src\claytek\engine.d  src\claytek\log.d  src\claytek\window.d src\claytek\input.d  src\claytek\timers.d -c -v -debug -Isrc -odobj\claytek
parse     engine
parse     log
parse     window
parse     input
parse     timers
semantic  engine
semantic  log
semantic  window
semantic  input
semantic  timers
semantic2 engine
semantic2 log
semantic2 window
semantic2 input
semantic2 timers
semantic3 engine
semantic3 log
semantic3 window
semantic3 input
semantic3 timers
code      engine
generating code for function 'this'
Error: undefined label quit

--- errorlevel 1

On generating the code for engine, it encountered an indefined label quit.

What does that mean? thanks.


« First   ‹ Prev
1 2