What's up with GDC?

[Joerg Joergonson via Digitalmars-d-learn]

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.