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
