Non-Windows users have the benefit of using a linker that has the ability to add search paths via command line, e.g.: dmd main.d -I../../src -L-lmylib -L-L../../ "mylib.a" will be search for in the relative directory ../../ We don't have this feature with Optlink. Our only option seems to be to locally create a "sc.ini" file, and then have something like this in it: [Version] version=7.51 Build 020 [Environment] DMDPATH=D:\DMD\dmd2\windows\bin LIB="%DMDPATH%\..\lib";\dm\lib;%cd%\..\..\ DFLAGS="-I%DMDPATH%\..\..\src\phobos" "-I%DMDPATH%\..\..\src\druntime\import" LINKCMD=%DMDPATH%\link.exe Note how I had to hardcode DMD's path there. It would be really beneficial if we had this option in optlink, otherwise we have to rely on external build tools to expand paths to any library files.
Actually, you can do that with the rather obscure notation dmd main.d -I..\..\src mylib.lib -L..\..\ The important part is the trailing backslash for the path that tells optlink that this is a search path. Unfortunately, this does not work if you also pass resource or definition files to the link process, because the link options are always passed at the end of the optlink command line. The search path then ends up in the wrong section of the command line. So, I'd also like an option to pass the library search path to the linker through dmd in a sensible way. BTW: The way to work with library paths in Visual D is to add some environment variable in the LIB statement of dmds global sc.ini file and use this to extend the library search path.
(In reply to comment #1) > Actually, you can do that with the rather obscure notation > > dmd main.d -I..\..\src mylib.lib -L..\..\ No, you can't. That's what I was saying. Look: .\fold1\fold2\main.d .\foo.d .\fold1\fold2\main.d: import foo; void main() { auto x = foothing(); } .\foo.d: int foothing() { return 1; } $ dmd -lib foo.d $ cd fold1\fold2 $ md main.d -I..\..\ foo.lib -L..\..\ OPTLINK : Warning 9: Unknown Option : NOI..\..\ foo.lib Warning 2: File Not Found foo.lib main.obj(main) The LIB environment variable would be very useful if the default sc.ini didn't overwrite it but prepend it by default. Instead of this line: LIB="%@P%\..\lib";\dm\lib we would have this line: LIB="%@P%\..\lib";\dm\lib;%LIB% Then I could actually use LIB via a shell script without having to touch sc.ini, e.g. continuing my previous example and with the sc.ini change I could do: $ set LIB=..\..\;%LIB% $ dmd main.d -I..\..\ foo.lib And voila, it works. But unfortunately the default sc.ini setting overwrites LIB instead of prepending to it.
Sorry, I did not think of the /NOI. We need a separator from the option, so this line works for me: dmd main.d -I..\..\src mylib.lib -L+..\..\ Regarding the LIB environment variable: I tend to use a name specific to dmd (DMDLIB) because LIB is also used by other compilers, but the libraries in their directories are not OMF and cause optlink to fail.
(In reply to comment #3) > Sorry, I did not think of the /NOI. We need a separator from the option, so > this line works for me: > > dmd main.d -I..\..\src mylib.lib -L+..\..\ > Holy cow that actually works! This has to be specified somewhere in the docs, maybe even the DMD switch docs because it's so useful with multiple static libraries. Thanks for the tip, Rainer!
FWIW I've updated the dwiki: http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/CompilingLinkingD#section5
Well crap, this syntax doesn't work if you use the -lib switch with DMD. Is there any workaround for this?
When building a library, it is generated by dmd, not by the linker. I guess there is no library search going on at all. If you create a library you usually don't add another library to it. Insterad, it is added in the link of the final executable. You can combine libraries with dmd, but I think this is a very explicite step, so not using a search path seems ok.
(In reply to comment #7) > If you create a library you usually don't add another library to it. You are right, this completely slipped my mind. :)