dmd -unittest -main -run: undefined reference to `_D1c12__ModuleInfoZ'

[ag0aep6g]

On 02.05.19 01:18, kdevel wrote:
> Now I have:
> 
> a/main.d
> a/b/package.d
> a/b/c/package.d
> 
> b/package.d and c/package.d as before.

For reference, a/b/c/package.d is this:

     module c; package import std.file;

And a/b/package.d starts with:

    module b; import c;

> a/main.d is
> 
> ```
> import b;
> 
> void dummy ()
> {
>     string s = "test";
>     mkdir (s);
> }
> ```
> 
> In cwd a/ with
> 
>     $ dmd -unittest -main -i -run main.d
> 
> I get
> 
>     b/package.d(2): Error: module `c` is in file 'c.d' which cannot be read
>     import path[0] = /.../dmd2/linux/bin64/../../src/phobos
>     import path[1] = /.../dmd2/linux/bin64/../../src/druntime/import
> 
> Why does dmd not get it?

If you want c to be part of the package b, you have to state that in the 
module declaration and when importing it.

In c/package.d:

     module b.c;

In b/package.d:

     import b.c;

Module declarations and imports are always absolute. They're not 
relative to the current package. If you add a new root directory on top, 
you have to adjust those declarations in all files.

> I have to supply -I=b explicitly. Which leads 
> me to
> the actual problem I wanted to post:
> 
>     $ dmd -unittest -main -I=b -run main.d
>     main.d(6): Error: undefined identifier mkdir

main only imports b. And b doesn't expose mkdir.

You can either import c (or rather b.c) in main, or make b's import of c 
public.

By the way, `package import` seems to work just like `public import`, 
not restricting anything. Looks like a compiler bug.

> The problem I see here is that b passes the isolated unittest. But when 
> it is used undefined symbols show up. I stumbled over this problem while 
> using a project as submodule which uses msgpack-d as its submodule. Only 
> if I restrict
> the import like in
> 
>     import msgpack : unpack, pack;
> 
> my submodule's unittest fails right away. My submodule corresponds to 
> b/package.d in this thread. I suppose the line
> 
>      package import std.file, core.stdc.string;
> 
> in msgpack-d's file packer.d causes the export of mkdir. Right?

"Export" in the sense of D identifier visibility, yes.

Note that an "undefined identifier" error is different from one about an 
"undefined reference". The former is the compiler saying it can't find 
the definition of a D identifier. The latter is the linker saying it 
can't find a symbol in the object files.