View mode: basic / threaded / horizontal-split · Log in · Help
February 14, 2005
Aargh! Darn "is in multiply defined" errors
I've had a few problems with getting "module X is in multiply defined" 
errors before and it usually turned out to be a cryptic way of saying "you 
need annother 'import' statement somewhere". (BTW, Is that going to be fixed 
sometime?)

I seem to be getting something  little weirder now though.  When I compile 
the sources seperately and then link them everything works fine, but when I 
try to compile and link everything in one call to dmd I'm getting that 
multiply defines error on each of my modules.
February 14, 2005
Re: Aargh! Darn
In article <cur6d7$1ueq$1@digitaldaemon.com>, Nick Sabalausky says...
>
>I've had a few problems with getting "module X is in multiply defined" 
>errors before and it usually turned out to be a cryptic way of saying "you 
>need annother 'import' statement somewhere". (BTW, Is that going to be fixed 
>sometime?)
>
>I seem to be getting something  little weirder now though.  When I compile 
>the sources seperately and then link them everything works fine, but when I 
>try to compile and link everything in one call to dmd I'm getting that 
>multiply defines error on each of my modules. 
>
>

Just a thought: are you making sure that you're using 'private import'?  

If your module has statements like this:

> // example module 'A'
> import std.stdio;
> import std.string;

Then when you import this in a separate file, you get problems:

> import A;
> import std.stdio; // causes collision

So go and change your imports to 'private' instead, since its likely what you're
intending to do:

> // (revised) example module 'A'
> private import std.stdio;
> private import std.string;


- EricAnderton at yahoo
February 14, 2005
Re: Aargh! Darn "is in multiply defined" errors
On Mon, 14 Feb 2005 16:49:38 -0500, Nick Sabalausky <z@a.a> wrote:
> I've had a few problems with getting "module X is in multiply defined"
> errors before and it usually turned out to be a cryptic way of saying  
> "you
> need annother 'import' statement somewhere". (BTW, Is that going to be  
> fixed
> sometime?)
>
> I seem to be getting something  little weirder now though.  When I  
> compile
> the sources seperately and then link them everything works fine, but  
> when I
> try to compile and link everything in one call to dmd I'm getting that
> multiply defines error on each of my modules.

I've seen/had this error when a module was missnamed i.e.

[foo.d]
module not_foo;

changing it to

[foo.d]
module foo;

fixes it, you might want to have a quick check that you don't have  
something like that. It may even be caused if the file is in the wrong  
directory i.e.

[c:\d\projects\foo\bar\baz.d]
module foo.not_bar.baz;

Regan
February 14, 2005
Re: Aargh! Darn
Yea, when I was getting the errors before, I went all paranoid and just 
turned everything into a private import.

"pragma" <pragma_member@pathlink.com> wrote in message 
news:cur81m$20jf$1@digitaldaemon.com...
> In article <cur6d7$1ueq$1@digitaldaemon.com>, Nick Sabalausky says...
>>
>>I've had a few problems with getting "module X is in multiply defined"
>>errors before and it usually turned out to be a cryptic way of saying "you
>>need annother 'import' statement somewhere". (BTW, Is that going to be 
>>fixed
>>sometime?)
>>
>>I seem to be getting something  little weirder now though.  When I compile
>>the sources seperately and then link them everything works fine, but when 
>>I
>>try to compile and link everything in one call to dmd I'm getting that
>>multiply defines error on each of my modules.
>>
>>
>
> Just a thought: are you making sure that you're using 'private import'?
>
> If your module has statements like this:
>
>> // example module 'A'
>> import std.stdio;
>> import std.string;
>
> Then when you import this in a separate file, you get problems:
>
>> import A;
>> import std.stdio; // causes collision
>
> So go and change your imports to 'private' instead, since its likely what 
> you're
> intending to do:
>
>> // (revised) example module 'A'
>> private import std.stdio;
>> private import std.string;
>
>
> - EricAnderton at yahoo
February 14, 2005
Re: Aargh! Darn "is in multiply defined" errors
"Regan Heath" <regan@netwin.co.nz> wrote in message 
news:opsl7kmthn23k2f5@ally...
> On Mon, 14 Feb 2005 16:49:38 -0500, Nick Sabalausky <z@a.a> wrote:
>> I've had a few problems with getting "module X is in multiply defined"
>> errors before and it usually turned out to be a cryptic way of saying 
>> "you
>> need annother 'import' statement somewhere". (BTW, Is that going to be 
>> fixed
>> sometime?)
>>
>> I seem to be getting something  little weirder now though.  When I 
>> compile
>> the sources seperately and then link them everything works fine, but 
>> when I
>> try to compile and link everything in one call to dmd I'm getting that
>> multiply defines error on each of my modules.
>
> I've seen/had this error when a module was missnamed i.e.
>
> [foo.d]
> module not_foo;
>
> changing it to
>
> [foo.d]
> module foo;
>
> fixes it, you might want to have a quick check that you don't have 
> something like that. It may even be caused if the file is in the wrong 
> directory i.e.
>
> [c:\d\projects\foo\bar\baz.d]
> module foo.not_bar.baz;
>
> Regan

I'm not using the module statement anywhere :(. Also, if it were a wrong 
directory issue, wouldn't I be getting the problem even when I compile the 
sources seperately?
February 14, 2005
Re: Aargh! Darn
> If your module has statements like this:
>
>> // example module 'A'
>> import std.stdio;
>> import std.string;
>
> Then when you import this in a separate file, you get problems:
>
>> import A;
>> import std.stdio; // causes collision

I couldn't reproduce this behavior. Can you post an example of where an 
import in A will cause a collision?
February 15, 2005
Re: Aargh! Darn "is in multiply defined" errors
On Mon, 14 Feb 2005 18:30:35 -0500, Nick Sabalausky wrote:

> "Regan Heath" <regan@netwin.co.nz> wrote in message 
> news:opsl7kmthn23k2f5@ally...
>> On Mon, 14 Feb 2005 16:49:38 -0500, Nick Sabalausky <z@a.a> wrote:
>>> I've had a few problems with getting "module X is in multiply defined"
>>> errors before and it usually turned out to be a cryptic way of saying 
>>> "you
>>> need annother 'import' statement somewhere". (BTW, Is that going to be 
>>> fixed
>>> sometime?)
>>>
>>> I seem to be getting something  little weirder now though.  When I 
>>> compile
>>> the sources seperately and then link them everything works fine, but 
>>> when I
>>> try to compile and link everything in one call to dmd I'm getting that
>>> multiply defines error on each of my modules.
>>
>> I've seen/had this error when a module was missnamed i.e.
>>
>> [foo.d]
>> module not_foo;
>>
>> changing it to
>>
>> [foo.d]
>> module foo;
>>
>> fixes it, you might want to have a quick check that you don't have 
>> something like that. It may even be caused if the file is in the wrong 
>> directory i.e.
>>
>> [c:\d\projects\foo\bar\baz.d]
>> module foo.not_bar.baz;
>>
>> Regan
> 
> I'm not using the module statement anywhere :(. Also, if it were a wrong 
> directory issue, wouldn't I be getting the problem even when I compile the 
> sources seperately?

I usually get this message when I do not use the module statement. In that
case, DMD invents the module name for you, which is typically just the
source file's name minus the path to the source file. And that's usually
the problem - I need to path (read "package") name as well as the module
name.
Anyhow, I've learned to always explicitly place a module name in the file
now, and to make sure it contains the complete package name too.

Of course, this is PITA when you decide to move files around to different
directories, but one doesn't do that too often (now, anyway).

-- 
Derek
Melbourne, Australia
15/02/2005 11:27:45 AM
February 15, 2005
Re: Aargh! Darn "is in multiply defined" errors
Derek Parnell wrote:
> On Mon, 14 Feb 2005 18:30:35 -0500, Nick Sabalausky wrote:

> Of course, this is PITA when you decide to move files around to different
> directories, but one doesn't do that too often (now, anyway).

And it will become so much less of a PITA when we get a D IDE with a 
refactoring tool on par with what's out there for Java!
February 15, 2005
Re: Aargh! Darn "is in multiply defined" errors
I'm personally dreaming of Borland releasing a DBuilder...

-- Chris S

Mike Parker wrote:
> And it will become so much less of a PITA when we get a D IDE with a 
> refactoring tool on par with what's out there for Java!
February 15, 2005
Re: Aargh! Darn "is in multiply defined" errors
"Derek Parnell" <derek@psych.ward> wrote in message 
news:1mayz93if5xd.xd6a5a6sct97$.dlg@40tude.net...
> On Mon, 14 Feb 2005 18:30:35 -0500, Nick Sabalausky wrote:
>
>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>> news:opsl7kmthn23k2f5@ally...
>>> On Mon, 14 Feb 2005 16:49:38 -0500, Nick Sabalausky <z@a.a> wrote:
>>>> I've had a few problems with getting "module X is in multiply defined"
>>>> errors before and it usually turned out to be a cryptic way of saying
>>>> "you
>>>> need annother 'import' statement somewhere". (BTW, Is that going to be
>>>> fixed
>>>> sometime?)
>>>>
>>>> I seem to be getting something  little weirder now though.  When I
>>>> compile
>>>> the sources seperately and then link them everything works fine, but
>>>> when I
>>>> try to compile and link everything in one call to dmd I'm getting that
>>>> multiply defines error on each of my modules.
>>>
>>> I've seen/had this error when a module was missnamed i.e.
>>>
>>> [foo.d]
>>> module not_foo;
>>>
>>> changing it to
>>>
>>> [foo.d]
>>> module foo;
>>>
>>> fixes it, you might want to have a quick check that you don't have
>>> something like that. It may even be caused if the file is in the wrong
>>> directory i.e.
>>>
>>> [c:\d\projects\foo\bar\baz.d]
>>> module foo.not_bar.baz;
>>>
>>> Regan
>>
>> I'm not using the module statement anywhere :(. Also, if it were a wrong
>> directory issue, wouldn't I be getting the problem even when I compile 
>> the
>> sources seperately?
>
> I usually get this message when I do not use the module statement. In that
> case, DMD invents the module name for you, which is typically just the
> source file's name minus the path to the source file. And that's usually
> the problem - I need to path (read "package") name as well as the module
> name.
> Anyhow, I've learned to always explicitly place a module name in the file
> now, and to make sure it contains the complete package name too.
>
> Of course, this is PITA when you decide to move files around to different
> directories, but one doesn't do that too often (now, anyway).
>
> -- 
> Derek
> Melbourne, Australia
> 15/02/2005 11:27:45 AM

Yay! That worked! :) But, I'm not sure I understand why it was having a 
problem when I didn't explicity state the module.

From working with the DMD compiler, this is how I understand things: Lets 
say I have a directory "C:\src\package\foo\" that contains the files 
"main.d" and "mymodule.d". Neither contain a module statement, and "main.d" 
needs to import the mymodule stuff. If I'm in the directory 
"C:\src\package\foo\" when I invoke DMD, then the import statement in 
"main.d" should be "import mymodule;".  However, if I'm in the directory 
"C:\src\" when I invoke DMD, then the line in "main.d" should be "import 
package.foo.mymodule;".  Hence, when I'm invoking from "C:\src\", doesn't 
DMD assume the name for the mymodule stuff to be "package.foo.mymodule" and 
not just "mymodule"? (And I realize, of course, that I could just pass the 
compiler "-I{dir}" instead of actually being in the given directory.)

Hmm, I think I might understand this...tell me if this is correct: Again, 
assume the same files and directory structure as before and that we're 
always invoking from "C:\src\" (Or that we're passing in "-IC:\src\"). When 
the compiler is told to compile "package\foo\mymodule.d" it strips out the 
path and names the module "mymodule". When the compiler parses 
"package\foo\main.d", it reads the line "import package.foo.mymodule;" and 
decides that it needs a module named "package.foo.mymodule". It then looks 
inside "package\foo\", finds the file "package\foo\mymodule.d", and then 
finishes compiling "package\foo\main.d". Then, when it's compiling 
"package\foo\mymodule.d" it strips out the path and names the module simply 
"mymodule". So basically, main.d is referencing the module 
"package.foo.mymodule" and mymodule.d is essentially referencing the module 
"mymodule". Thus we have a conflict between "package.foo.mymodule" and 
"mymodule".

Is this correct? If so, then shouldn't the compiler *not* strip the path?
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home