On Saturday, 11 June 2016 at 08:48:42 UTC, Mike Parker wrote:
On Saturday, 11 June 2016 at 06:22:27 UTC, Joerg Joergonson
wrote:
[...]
That's not true unless I'm not suppose to import them
directly. When I switch to 64-bit build I get same errors.
Basically only dmd x86 works.
It's true if everything is configured properly.
1. How to tell the difference between different libs and what
kind of libs are required for what kind of compiler and build.
x86 x64
DMD . .
LDC . .
GDC . .
Please fill in the table for windows, linux, etc.
On Windows/Mac/FreeBSD, if you know how to configure libraries
for gcc, then you know how to configure them with DMD. You
install the packages you need from your package manager, they
are installed by default in the appropriate system paths, and
when DMD invokes the system linker they will be found.
Windows is only problematic because there's no such thing as a
system linker, nor are there any standard system paths for
libraries. Given the following command line:
dmd foo.d user32.lib
The compiler will invoke OPTLINK, which it ships with. This
guarantees that you always have a linker if DMD is installed.
You will find several Win32 libraries in the dmd2/windows/lib
directory. They are all a in OMF format for OPTLINK and they
are all a bit outdated. With the above command line, the
user32.lib in that directory will be used. If you need a Win32
system library that does not ship with DMD (such as
OpenGL32.lib) you will need to provide it yourself in the OMF
format to use it with OPTLINK.
Add either the -m32mscoff or -m64 command line switch and DMD
will invoke whichever Microsoft linker it is configured to
call, meaning it will no longer use the libraries that ship
with DMD. If you've installed one of paid versions of VS, or
one of the Community Editions, all of the Win32 libraries will
be installed as well. If you're using one of the VS Express
versions, you'll need a Windows SDK installed to have the Win32
libraries.
2. How does the D build system fetch the libs? It uses the
sci.ini path? What about Visual D?
Yes, on Windows, sc.ini is where the library paths are
configured. If you installed DMD manually, or used the
installer but installed Visual Studio after, then you will need
to edit sc.ini to make sure the paths point to the proper VS
locations. If run the DMD installer *after* installing Visual
Studio, the installer will configure sc.ini for you. I
recommend you take that approach. It just works.
On other systems, dmd.conf is used to configure the location of
libphobos2, but system libraries are on the system path (just
as when using gcc).
Where does D look for these? I assume in the "libs" directory?
pragma(lib, "opengl32");
pragma(lib, "glu32");
On Windows, it looks on the path configured in sc.ini or
whatever import path you have provided on the command line with
-I, just as it does with any libraries you pass on the command
line. So that means that compiling without -m32mscoff or -m64,
it looks win the dmd2/windows/lib directory. Since opengl32 and
glu32 do not ship with DMD, it will not find them there. So you
either need to put COFF format libs there or tell the compiler
where to find them with -I. With -m32mscoff or -m64, it looks
for the Microsoft version of those libraries in the Visual
Studio or Windows SDK installation, which you should have
configured in sc.ini as I explained above.
On other systems, the OpenGL libraries are found on the system
library path.
3. How to get different compilers and versions to play along?
I would eventually like to build for win/lin/osx for both x64
and x86.
On Windows, Just make sure you provide any third-party
libraries you need, along with any system libraries you need
that DMD does not ship with, in the OMF format when using
OPTLINK on Windows and tell DMD where to find them. When using
the MS toolchain, the system libraries are all there, so you
need not provide any. You'll just need to make sure any
third-party libraries are in the COFF format (preferably
compiled with the same version of Visual Studio you are using
to link your D programs).
On Linuux and OSX, just make sure the dev packages of any
libraries you need are installed. You do need to account for
different libray names (e.g. Openg32.lib on Windows vs.
libopengl elswhere, so your pragmas above should include '32'
in the name only on Windows).
Alternatively, you might try one of the dynamic bindings[1] to
a library you need, such as DerelictGL3. Then there is no link
time dependency, as the shared libraries are loaded at runtime.
On Windows, that completely eliminates the COFF vs. OMF issues.
As long as the DLLs match your executable's architecture
(32-bit vs. 64-bit), then it doesn't matter what compiler was
used to create them when loading them at runtime.
I am using Visual D, BTW. It seems to have a lot of stuff
setup by default but I haven't went in and messed with the
settings much.
Well, when it invokes DMD, the compiler uses whatever you've
configured in sc.ini for the system libraries. Anything else
you can configure in Visual D's project settings.
Well, it's definitely not as simple as you make it out to be. I
have tried all kinds of combinations of libs and settings and
nothing works. If it's not one error it's another and it becomes
hard to know exactly what is going on because the people who
created these applications didn't have the forethought to give
meaningful error messages.
I believe the main problem now is that ldc is not linking phobo's
or runtime or whatever because I get all kinds of weird export
issues.
with x86 ldc I get
Error: module libsmBase is in file 'libsmBase.d' which cannot be
read.
The module though is actually mBase and it is in libs\mBase. It
removing the directory.
From the build:
echo libs\mBase.d >"Win32\Debug LDC\Test.build.rsp"
So, not sure if the error is just leaving out the '\' or what.
Irregardless, please don't act like all this is my problem
because most of it is due to crappy design and forethought.
Maybe I am suppose to include the subdirs in my project in visual
studio/D and the error message simply cannot find the modules?
But how am I suppose to know that with an illogical error message
like what is above?
DMD works fine BTW. GDC and LDC should be a drop in replacement.
Not a totally new setup that has it's own set of problems. I'm
sure I'm not the only one put off by the compounding of problems
when using D.
