Hello,

I am new to d and doing some small test apps at the moment to learn d. Currently I must be missing something basic here. I have installed dub as a project manager and I am trying to use a .lib file in an app. However, I can not use a module from the .lib file. I get the following error:

"module barlib is in file 'barlib.d' which cannot be read"

here is what I currently have:

the file to build the library
-----------------------------
module barlib;
import std.stdio;

class BarLib
{
this(){}
	void Talk(string msg)
	{
		writeln("BL: %s", msg);
	}
}

the dub.json to build the lib
-----------------------------
{
	"name": "dbar",
	"authors": ["moe"],
	"description": "A minimal D application.",
	"copyright": "Copyright © 2016, root",
	"license": "proprietary",
	"platforms": ["windows"],
	"versions": ["DesktopApp"],
	"targetType": "staticLibrary",
	"configurations": [
	{
		"name": "debug",
		"targetPath": "bin/debug",
		"buildOptions": ["debugMode", "debugInfo"]
	},
	{
		"name": "release",
		"targetPath": "bin/release",
		"buildOptions": ["releaseMode", "optimize", "inline"]
	}
	]
}


the file for the app
--------------------
import barlib;
import std.stdio;

void main()
{
	auto b = new BarLib();
	b.Talk("Hello from barlib");
}

the dub.json for the app
------------------------
{
	"name": "dfoo",
	"authors": ["moe"],
	"description": "A minimal D application.",
	"copyright": "Copyright © 2016, root",
	"license": "proprietary",
	"platforms": ["windows"],
	"versions": ["DesktopApp"],
	"targetType": "executable",
	"configurations": [
	{
		"name": "debug",
		"targetPath": "bin/debug",
		"buildOptions": ["debugMode", "debugInfo"]
	},
	{
		"name": "release",
		"targetPath": "bin/release",
		"buildOptions": ["releaseMode", "optimize", "inline"]
	}
	]
}

I can successfully build the barlib.lib file but I can not use it in the app. I thought that it should be possible to simply import the module from the lib-file, but the app cannot find the module. I would like to be able to build .lib and .dll files and use them in other applications. Can someone tell me what I am missing?

On Sunday, 19 June 2016 at 15:35:04 UTC, moe wrote:

> I am new to d and doing some small test apps at the moment to learn d. Currently I must be missing something basic here. I have installed dub as a project manager and I am trying to use a .lib file in an app. However, I can not use a module from the .lib file. I get the following error:
>
> "module barlib is in file 'barlib.d' which cannot be read"

This is a compile time error, not a link time error. Imports modules and linking to libraries are two different things.

>
> the dub.json for the app
> ------------------------
> {
> 	"name": "dfoo",
> 	"authors": ["moe"],
> 	"description": "A minimal D application.",
> 	"copyright": "Copyright © 2016, root",
> 	"license": "proprietary",
> 	"platforms": ["windows"],
> 	"versions": ["DesktopApp"],
> 	"targetType": "executable",
> 	"configurations": [
> 	{
> 		"name": "debug",
> 		"targetPath": "bin/debug",
> 		"buildOptions": ["debugMode", "debugInfo"]
> 	},
> 	{
> 		"name": "release",
> 		"targetPath": "bin/release",
> 		"buildOptions": ["releaseMode", "optimize", "inline"]
> 	}
> 	]
> }
>

Nowhere have you set up barlib as a dependency for your app, so DUB has no idea it's supposed to tell dmd that you need to link to the library or where to find the modules. So the easy thing to do is to add a dependency directive. Since your library isn't registered with the dub registry, you'll need to provide a path to the barlib dub project rather than a release tag for the library.

Assuming a directory tree like so:
-projects
--barlib
---dub.json
--dfoo
---dub.json

Then the path for dfoo's depencency is ../barlib. With a dub.sdl file, it would look like this:

dependency "barlib" path="../barlib"

You can find the equivalent JSON syntax somewhere at [1]. With this, dub will manage your import path and library dependency for you.

> I can successfully build the barlib.lib file but I can not use it in the app. I thought that it should be possible to simply import the module from the lib-file, but the app cannot find the module. I would like to be able to build .lib and .dll files and use them in other applications. Can someone tell me what I am missing?

Compiling and linking are two distinct steps. The compiler passes any libraries you give it to the linker, but it does not do anything with them itself during the compile step. At that stage, it's only concerned with source modules. So you need to tell it: where to find the source modules (on the command line), which ones to import (with the import statement). It also needs to know which libraries to pass to the linker and where they can be found.

Give the directory tree above, when compiling dfoo manually, you might do this on Windows:

cd dfoo
dmd -I../barlib/source source/app.d ../barlib/bin/barlib.lib

On other systems:

dmd -I../barlib/source -L-L../barlib/bin -L-lbarlib source/app.d

The -I switch tells the compiler where it can find the modules you need to import. DRuntime and Phobos are configured in DMD's config files, so you don't need to every specify those. On the windows command line, you can pass the full path to the library directly and the compiler will do the right thing. This is easier than dealing with the different syntax the two supported Windows linkers use for command line switches. On Posix systems, it's better to use the -L switch, which tell the compiler the immediately following command should be passed to the system linker. Ex:

-L-L/some/path -> passes -L/some/path to the linker, which is the switch telling it where to look for libraries.
-L-lFoo (-L-l -- the second letter is a lowercase 'L') -> passes -lname to the linker, telling it which library to link with.

Given this, the linker will look for /some/path/libFoo.so or /some/path/libFoo.a, in addition to searching the normal search paths.

As you can see, it's easier to properly configure your dub.json dependecies so that DUB can handle all of this for you.

[1] http://code.dlang.org/package-format?lang=json

On Sunday, 19 June 2016 at 16:31:40 UTC, Mike Parker wrote:
> On Sunday, 19 June 2016 at 15:35:04 UTC, moe wrote:
>
>> I am new to d and doing some small test apps at the moment to learn d. Currently I must be missing something basic here. I have installed dub as a project manager and I am trying to use a .lib file in an app. However, I can not use a module from the .lib file. I get the following error:
>>
>> "module barlib is in file 'barlib.d' which cannot be read"
>
> This is a compile time error, not a link time error. Imports modules and linking to libraries are two different things.
>
>>
>> the dub.json for the app
>> ------------------------
>> {
>> 	"name": "dfoo",
>> 	"authors": ["moe"],
>> 	"description": "A minimal D application.",
>> 	"copyright": "Copyright © 2016, root",
>> 	"license": "proprietary",
>> 	"platforms": ["windows"],
>> 	"versions": ["DesktopApp"],
>> 	"targetType": "executable",
>> 	"configurations": [
>> 	{
>> 		"name": "debug",
>> 		"targetPath": "bin/debug",
>> 		"buildOptions": ["debugMode", "debugInfo"]
>> 	},
>> 	{
>> 		"name": "release",
>> 		"targetPath": "bin/release",
>> 		"buildOptions": ["releaseMode", "optimize", "inline"]
>> 	}
>> 	]
>> }
>>
>
> Nowhere have you set up barlib as a dependency for your app, so DUB has no idea it's supposed to tell dmd that you need to link to the library or where to find the modules. So the easy thing to do is to add a dependency directive. Since your library isn't registered with the dub registry, you'll need to provide a path to the barlib dub project rather than a release tag for the library.
>
> Assuming a directory tree like so:
> -projects
> --barlib
> ---dub.json
> --dfoo
> ---dub.json
>
> Then the path for dfoo's depencency is ../barlib. With a dub.sdl file, it would look like this:
>
> dependency "barlib" path="../barlib"
>
> You can find the equivalent JSON syntax somewhere at [1]. With this, dub will manage your import path and library dependency for you.
>
>> I can successfully build the barlib.lib file but I can not use it in the app. I thought that it should be possible to simply import the module from the lib-file, but the app cannot find the module. I would like to be able to build .lib and .dll files and use them in other applications. Can someone tell me what I am missing?
>
> Compiling and linking are two distinct steps. The compiler passes any libraries you give it to the linker, but it does not do anything with them itself during the compile step. At that stage, it's only concerned with source modules. So you need to tell it: where to find the source modules (on the command line), which ones to import (with the import statement). It also needs to know which libraries to pass to the linker and where they can be found.
>
> Give the directory tree above, when compiling dfoo manually, you might do this on Windows:
>
> cd dfoo
> dmd -I../barlib/source source/app.d ../barlib/bin/barlib.lib
>
> On other systems:
>
> dmd -I../barlib/source -L-L../barlib/bin -L-lbarlib source/app.d
>
> The -I switch tells the compiler where it can find the modules you need to import. DRuntime and Phobos are configured in DMD's config files, so you don't need to every specify those. On the windows command line, you can pass the full path to the library directly and the compiler will do the right thing. This is easier than dealing with the different syntax the two supported Windows linkers use for command line switches. On Posix systems, it's better to use the -L switch, which tell the compiler the immediately following command should be passed to the system linker. Ex:
>
> -L-L/some/path -> passes -L/some/path to the linker, which is the switch telling it where to look for libraries.
> -L-lFoo (-L-l -- the second letter is a lowercase 'L') -> passes -lname to the linker, telling it which library to link with.
>
> Given this, the linker will look for /some/path/libFoo.so or /some/path/libFoo.a, in addition to searching the normal search paths.
>
> As you can see, it's easier to properly configure your dub.json dependecies so that DUB can handle all of this for you.
>
> [1] http://code.dlang.org/package-format?lang=json

Thanks for the reply.

Unfortunatelly I still don't get it. I would like to have an independant project "dbar". The created lib is then used in another project "dfoo". Assuming that "dfoo" has no access to "dbar" other than the .lib file.

My folder structure is like this:

-dtest
--dbar
----source\barlib.d
----dub.json
This project creates a dbar.lib file which seams to work.


-dtest
--dfoo
----lib\dbar.d  // copied from the dbar project
----source\app.d
----dub.json
This project would use the dbar.lib but should otherwise not have access to the dbar project. Basically simulating, that someone else made a dbar project to which I would not have access other than using the dbar.lib. How do I have to configure the dub.json file for this to work?

I have tried a variety of configurations for the dub.json. At this point it feels like a bad guessing game. That is no way to deveop anything. I need to figure out how to properly setup the dub.json but I don't seam to find the answer online. "http://code.dlang.org/package-format?lang=json" isn't very helpful.

I have meanwhile adjusted my dtest/dfoo/dub.json to this:
{
	"name": "dfoo",
	"authors": ["moe"],
	"description": "A minimal D application.",
	"copyright": "Copyright © 2016, root",
	"license": "proprietary",
	"platforms": ["windows"],
	"versions": ["DesktopApp"],
	"targetType": "executable",
	"sourcePaths":["lib"],
	"libs": ["dbar"],
	"copyFiles": ["lib"],
	"dependencies": {
		"dbar": "~master"
	},
	"configurations": [
	{
		"name": "debug",
		"targetPath": "bin/debug",
		"buildOptions": ["debugMode", "debugInfo"],
	},
	{
		"name": "release",
		"targetPath": "bin/release",
		"buildOptions": ["releaseMode", "optimize", "inline"],
	}
	]
}
This gives me the error: "Root package dfoo references unknown package dbar"

Removing the dependencies doesn't work either.

On Sunday, 19 June 2016 at 17:33:43 UTC, moe wrote:
> On Sunday, 19 June 2016 at 16:31:40 UTC, Mike Parker wrote:
>> [...]
>
> Thanks for the reply.
>
> Unfortunatelly I still don't get it. I would like to have an independant project "dbar". The created lib is then used in another project "dfoo". Assuming that "dfoo" has no access to "dbar" other than the .lib file.
>
> [...]

Darn, I can't seam to edit the post. The line:
"----lib\dbar.d  // copied from the dbar project"

should of course read:
----lib\dbar.lib  // copied from the dbar project

I am copying the lib file. Not the .d file.

On Sunday, 19 June 2016 at 17:33:43 UTC, moe wrote:







> Unfortunatelly I still don't get it. I would like to have an independant project "dbar". The created lib is then used in another project "dfoo". Assuming that "dfoo" has no access to "dbar" other than the .lib file.

You can't do it with only the lib file. You *need* the source file too for the import statement. As I explained, the lib file is used by the linker, not the compiler. The compiler needs the source file.

>
> My folder structure is like this:
>
> -dtest
> --dbar
> ----source\barlib.d
> ----dub.json
> This project creates a dbar.lib file which seams to work.
>
>
> -dtest
> --dfoo
> ----lib\dbar.d  // copied from the dbar project
> ----source\app.d
> ----dub.json

You don't need to copy dbar to the lib directory in this case.

> This project would use the dbar.lib but should otherwise not have access to the dbar project. Basically simulating, that someone else made a dbar project to which I would not have access other than using the dbar.lib. How do I have to configure the dub.json file for this to work?

One of two things would happen:

1) They would register the project with he dub registry, then you add a dependency to a specific version the library. Dub would then download the necessary files for you and ensure that everything you need is passed to the compiler when building your project.

2) They would provide some other means for you to get the source and the library. Then you would need to manually configure your dub.json to pass the import path to the compiler and link with the library.

>
> I have tried a variety of configurations for the dub.json. At this point it feels like a bad guessing game. That is no way to deveop anything. I need to figure out how to properly setup the dub.json but I don't seam to find the answer online. "http://code.dlang.org/package-format?lang=json" isn't very helpful.

All the information you need is there on that page.

>
> I have meanwhile adjusted my dtest/dfoo/dub.json to this:

> 	"dependencies": {
> 		"dbar": "~master"
> 	}

> This gives me the error: "Root package dfoo references unknown package dear"

As I explained above, you need a path attribute for the dependency in this case since it is on your local file system and not in the registry. The documentation link I gave you explains how to to this. Try this:

"dependencies": {
    "dbar":  {"path": "../dbar"}
}

On Sunday, 19 June 2016 at 18:00:07 UTC, Mike Parker wrote:
> On Sunday, 19 June 2016 at 17:33:43 UTC, moe wrote:
>
>
>
>
>
>
>
>> Unfortunatelly I still don't get it. I would like to have an independant project "dbar". The created lib is then used in another project "dfoo". Assuming that "dfoo" has no access to "dbar" other than the .lib file.
>
> You can't do it with only the lib file. You *need* the source file too for the import statement. As I explained, the lib file is used by the linker, not the compiler. The compiler needs the source file.
>
>>
>> My folder structure is like this:
>>
>> -dtest
>> --dbar
>> ----source\barlib.d
>> ----dub.json
>> This project creates a dbar.lib file which seams to work.
>>
>>
>> -dtest
>> --dfoo
>> ----lib\dbar.d  // copied from the dbar project
>> ----source\app.d
>> ----dub.json
>
> You don't need to copy dbar to the lib directory in this case.
>
>> This project would use the dbar.lib but should otherwise not have access to the dbar project. Basically simulating, that someone else made a dbar project to which I would not have access other than using the dbar.lib. How do I have to configure the dub.json file for this to work?
>
> One of two things would happen:
>
> 1) They would register the project with he dub registry, then you add a dependency to a specific version the library. Dub would then download the necessary files for you and ensure that everything you need is passed to the compiler when building your project.
>
> 2) They would provide some other means for you to get the source and the library. Then you would need to manually configure your dub.json to pass the import path to the compiler and link with the library.
>
>>
>> I have tried a variety of configurations for the dub.json. At this point it feels like a bad guessing game. That is no way to deveop anything. I need to figure out how to properly setup the dub.json but I don't seam to find the answer online. "http://code.dlang.org/package-format?lang=json" isn't very helpful.
>
> All the information you need is there on that page.
>
>>
>> I have meanwhile adjusted my dtest/dfoo/dub.json to this:
>
>> 	"dependencies": {
>> 		"dbar": "~master"
>> 	}
>
>> This gives me the error: "Root package dfoo references unknown package dear"
>
> As I explained above, you need a path attribute for the dependency in this case since it is on your local file system and not in the registry. The documentation link I gave you explains how to to this. Try this:
>
> "dependencies": {
>     "dbar":  {"path": "../dbar"}
> }

I see where I went wrong. I thought that it's possible to only use the .lib file without the source code of dbar. Having access to the source makes what I am trying somewhat pointless. Is it otherwise possible to provide some functionality without having to give away your source? I would like to put together a library that I can reuse, without having to rely on the source each time. Maybe a dll instead?

Note: I don't have a problem with giving away my code. I just want to know if it can be done. Or maybe later build a plugin system where the creator of the plugin does not need the source of the entire application. And in turn the app does not need to be recompiled in order to use the plugin.

Thanks for your help!

On Sunday, 19 June 2016 at 18:33:36 UTC, moe wrote:
> On Sunday, 19 June 2016 at 18:00:07 UTC, Mike Parker wrote:
>> On Sunday, 19 June 2016 at 17:33:43 UTC, moe wrote:
>>
>>
>>
>>
>>
>>
>>
>>> Unfortunatelly I still don't get it. I would like to have an independant project "dbar". The created lib is then used in another project "dfoo". Assuming that "dfoo" has no access to "dbar" other than the .lib file.
>>
>> You can't do it with only the lib file. You *need* the source file too for the import statement. As I explained, the lib file is used by the linker, not the compiler. The compiler needs the source file.
>>
>>>
>>> My folder structure is like this:
>>>
>>> -dtest
>>> --dbar
>>> ----source\barlib.d
>>> ----dub.json
>>> This project creates a dbar.lib file which seams to work.
>>>
>>>
>>> -dtest
>>> --dfoo
>>> ----lib\dbar.d  // copied from the dbar project
>>> ----source\app.d
>>> ----dub.json
>>
>> You don't need to copy dbar to the lib directory in this case.
>>
>>> This project would use the dbar.lib but should otherwise not have access to the dbar project. Basically simulating, that someone else made a dbar project to which I would not have access other than using the dbar.lib. How do I have to configure the dub.json file for this to work?
>>
>> One of two things would happen:
>>
>> 1) They would register the project with he dub registry, then you add a dependency to a specific version the library. Dub would then download the necessary files for you and ensure that everything you need is passed to the compiler when building your project.
>>
>> 2) They would provide some other means for you to get the source and the library. Then you would need to manually configure your dub.json to pass the import path to the compiler and link with the library.
>>
>>>
>>> I have tried a variety of configurations for the dub.json. At this point it feels like a bad guessing game. That is no way to deveop anything. I need to figure out how to properly setup the dub.json but I don't seam to find the answer online. "http://code.dlang.org/package-format?lang=json" isn't very helpful.
>>
>> All the information you need is there on that page.
>>
>>>
>>> I have meanwhile adjusted my dtest/dfoo/dub.json to this:
>>
>>> 	"dependencies": {
>>> 		"dbar": "~master"
>>> 	}
>>
>>> This gives me the error: "Root package dfoo references unknown package dear"
>>
>> As I explained above, you need a path attribute for the dependency in this case since it is on your local file system and not in the registry. The documentation link I gave you explains how to to this. Try this:
>>
>> "dependencies": {
>>     "dbar":  {"path": "../dbar"}
>> }
>
> I see where I went wrong. I thought that it's possible to only use the .lib file without the source code of dbar. Having access to the source makes what I am trying somewhat pointless. Is it otherwise possible to provide some functionality without having to give away your source? I would like to put together a library that I can reuse, without having to rely on the source each time. Maybe a dll instead?
>
> Note: I don't have a problem with giving away my code. I just want to know if it can be done. Or maybe later build a plugin system where the creator of the plugin does not need the source of the entire application. And in turn the app does not need to be recompiled in order to use the plugin.
>
> Thanks for your help!

Sure, you can just have a file with "extern" functions that tells the compiler that the source for those functions isn't available at compile time, but that later on when you link the library, the linker will find those function definitions in the .lib file (I'm not a Windows expert, but from my understanding .DLLs are a different ball game, and have to be loaded and called with special functions in your app.)

In your example, in your "dfoo.d", you can declare the functions from the dbar.lib inside as "extern myfunction();" and the compiler will say, "OK, myfunction() isn't defined here, so we'll let the linker sort it out." If you try and compile without telling it about dbar.lib, you'll get errors like "undefined reference to myfunction()...".

When you see that somebody wrote a "binding" in D for a library like OpenGL, etc., this is what they are providing, a .d file filled with "extern" definitions and maybe some glue code to convert D types into C types if the .lib file is a C library.

APIs generally work the same way. Library writers will provide a .h header file that doesn't expose any of their closed source, but gives users of the library the definitions of the functions they need to use it's functions.

I hope this helps!

-Jon

On 2016-06-20 06:33, moe wrote:
> I see where I went wrong. I thought that it's possible to only use the
> .lib file without the source code of dbar. Having access to the source
> makes what I am trying somewhat pointless. Is it otherwise possible to
> provide some functionality without having to give away your source? I
> would like to put together a library that I can reuse, without having to
> rely on the source each time. Maybe a dll instead?

for this purpose there are .di interface files that can be generated automatically:
https://dlang.org/dmd-windows.html#interface-files

On Sunday, 19 June 2016 at 18:33:36 UTC, moe wrote:

>
> I see where I went wrong. I thought that it's possible to only use the .lib file without the source code of dbar. Having access to the source makes what I am trying somewhat pointless. Is it otherwise possible to provide some functionality without having to give away your source? I would like to put together a library that I can reuse, without having to rely on the source each time. Maybe a dll instead?
>
> Note: I don't have a problem with giving away my code. I just want to know if it can be done. Or maybe later build a plugin system where the creator of the plugin does not need the source of the entire application. And in turn the app does not need to be recompiled in order to use the plugin.

DLLs also have nothing to do with compilation. That's a runtime thing. D is not like Java, where everything you need is bundled in an archive and can be used at both compile time and runtime. It's more like C and C++, where there are very distinct formats in use and compile time and runtime. The compiler needs to know which symbols are available for you to use in your module. It can only get them from the source for the modules you import, not from any static libraries or DLLs.

D does support interface files (called 'D Interface' files, with a .di extension). These are stripped down versions of your source code that can be shipped with your binary. Instead of having full function implementations, you have the declarations only. This means that none of those functions can be inlined. And you still need the full implementation of any templates in the library, otherwise the templates can't be instantiated. .di files are more like C and C++ header files. You can generate them from any D source file by passing -H on the command line during compilation.

The primary benefit of .di files is to hide the source. Since you say you don't care about that, you probably shouldn't worry about them.

Really, if you are using DUB to manage your projects and don't care about hiding the source, then there's nothing to worry about. You can put your libraries on github or BitBucket, register them with the DUB registry at code.dlang.org, and then everyone who uses them as dependencies will have everything they need automatically. You could also bundle them up in zip files and distribute them that way. People can run dub to compile the libraries and then configure their project locally to find what they need. It isn't a problem at all.

Thanks everyone for the info. It is very much appreciated!

What works for me right now is dealing with various packages (dub packages) and use them in projects. I previously made too many assumptions about how lib's and dll's work. It's much clearer now.

Where I still have a problem is with a plugin system. I would like to write an app that is plugin based. So that I can write a plugin to extend the functionality of the app. I imagine that I could copy the plugin into a folder from the (compiled) app and the app would be able to use the plugin without me having to recompile the app. I have been looking at LoadLibrary (https://dlang.org/library/core/runtime/runtime.load_library.html) and Object.factory (https://dlang.org/library/object/object.factory.html) but I don't quite get how to use them. I did find some info that was several years old. They mentioned that these functions are not yet ready for all platforms. I don't know if that has changed in the meantime. It is not clear from the documentation.

I would like to find some snippets or examples but that sort of resource for D is very hard to find online. Most of the time there are only some partial snippets where it turns out they only work under specific conditions or are restricted to one platform. Does D not supply some infrastructure for this kind of a task? It seams to me that is a very common approach to build an app. I expected there would be some out of the box solution for this in D. I would write the app and the plugins purely in D (no C bindings if possible).

I have tried to build a mini app which defines an interface for the plugins. The plugins then implement that interface. But when I want to load the plugin both LoadLibrary() and Object.factory() fail (I am aware that Object.factory() requires the full qualified class names).

Is there a recommended way of writing a simple plugin system that works on windows and linux? Maybe someone has a working example or knows a book that covers how to write a plugin system?