On Saturday, 11 June 2016 at 01:43:21 UTC, Adam D. Ruppe wrote:
> On Friday, 10 June 2016 at 22:01:15 UTC, Joerg Joergonson wrote:
>> The problem I'm getting with ldc, using your simpledisplay, is that the libs aren't loading due to the wrong format.
>
>
> What's the exact message and what did you do? The opengl32.lib I have on my github is for dmd 32 bit, ldc uses the Microsoft one I think so you shouldn't need anything else.

It just says the format is invalid. I used the one you supplied in the package and never worried about it. I'll try some other libs when I get a chance.

BTW I make your code a bit better with resizing


case WM_SIZING:
    goto size_changed;
break;
case WM_ERASEBKGND: 				
	break;


Handling the erase background prevents windows from clearing the window, even with open GL. This allows resizing the window to still show the content. The only problem with it is that it seems the opengl code shifts up and down as the resize happens... It is probably an issue with the size change updates. It's pretty minor though and better than what it was(when I'd resize the window would go white and stay white as long as mouse was moving)

The specific errors are

opengl32.lib : warning LNK4003: invalid library format; library ignored
glu32.lib : warning LNK4003: invalid library format; library ignored

On Saturday, 11 June 2016 at 04:20:38 UTC, Joerg Joergonson wrote:
> On Saturday, 11 June 2016 at 01:43:21 UTC, Adam D. Ruppe wrote:

>> What's the exact message and what did you do? The opengl32.lib I have on my github is for dmd 32 bit, ldc uses the Microsoft one I think so you shouldn't need anything else.
>
> It just says the format is invalid. I used the one you supplied in the package and never worried about it. I'll try some other libs when I get a chance.
>

OpenGL32.lib and glu32.lib are part of the Windows SDK. Assuming you've got VS 2015 installed, they should be part of the installation and should be available out of the box. Adam's lib is solely for use with OPTLINK when compiling with DMD using the default -m32 on Windows, since DMD does not ship with the opengl lib. When compiling with -m32mscoff or -m64, it will use Visual Studios libraries.

On Saturday, 11 June 2016 at 05:12:56 UTC, Mike Parker wrote:
> On Saturday, 11 June 2016 at 04:20:38 UTC, Joerg Joergonson wrote:
>> On Saturday, 11 June 2016 at 01:43:21 UTC, Adam D. Ruppe wrote:
>
>>> What's the exact message and what did you do? The opengl32.lib I have on my github is for dmd 32 bit, ldc uses the Microsoft one I think so you shouldn't need anything else.
>>
>> It just says the format is invalid. I used the one you supplied in the package and never worried about it. I'll try some other libs when I get a chance.
>>
>
> OpenGL32.lib and glu32.lib are part of the Windows SDK. Assuming you've got VS 2015 installed, they should be part of the installation and should be available out of the box. Adam's lib is solely for use with OPTLINK when compiling with DMD using the default -m32 on Windows, since DMD does not ship with the opengl lib. When compiling with -m32mscoff or -m64, it will use Visual Studios libraries.

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 could be my setup.

This is EXACTLY what anyone who is doing this sort of stuff needs to know:

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.

If I know this information then it is at least easy to make sure I have matching socks. Else it's kinda pointless to put on shoes?


2. How does the D build system fetch the libs? It uses the sci.ini path? What about Visual D?

Just because I have the correct stuff from 1 doesn't mean it is in the "correct" place.

Where does D look for these? I assume in the "libs" directory?
   pragma(lib, "opengl32");
   pragma(lib, "glu32");

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.

Without these 3 ingredients, everything is futile!


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.

On Saturday, 11 June 2016 at 06:22:27 UTC, Joerg Joergonson wrote:
>>
>> OpenGL32.lib and glu32.lib are part of the Windows SDK. Assuming you've got VS 2015 installed, they should be part of the installation and should be available out of the box. Adam's lib is solely for use with OPTLINK when compiling with DMD using the default -m32 on Windows, since DMD does not ship with the opengl lib. When compiling with -m32mscoff or -m64, it will use Visual Studios libraries.
>
> 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.

On Saturday, 11 June 2016 at 08:48:42 UTC, Mike Parker wrote:

> 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

Obviously, I meant 'OMF format' here.

On Saturday, 11 June 2016 at 08:48:42 UTC, Mike Parker wrote:

> Alternatively, you might try one of the dynamic bindings[1] to a library you need, such as DerelictGL3. Then there is no link

[1] https://github.com/DerelictOrg

On Saturday, 11 June 2016 at 08:48:42 UTC, Mike Parker wrote:
[... a lot ...]

This looks like a nice writeup Mike, could you get this on the Wiki or somewhere more permanent where people can find it?

-Johan

Real professionals won't have difficulties to find binaries for ldc: https://github.com/ldc-developers/ldc/releases

--
Bien cordialement,
Ch.Meessen

> Le 10 juin 2016 à 22:30, Joerg Joergonson via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> a écrit :
> 
>> On Friday, 10 June 2016 at 19:51:19 UTC, Johan Engelen wrote:
>>> On Friday, 10 June 2016 at 19:37:13 UTC, Joerg Joergonson wrote:
>>> arm-linux-genuabi? arm-linux-gnueableihfqueridsofeyfh?  aifh-fkeif-fjjjjjjjj-fdsskjhfkjfafaaaaaa?
>> 
>> Rofl!
>> 
>>> and ldc requires building from sources(actually I didn't have too much trouble with installing it but it doesn't work with my libs because of the crappy coff issues that D has had since birth(it's like a tumor)).
>> 
>> Why do you have to build from sources? Any details about the problems you see?
>> 
>> Thanks,
>>  Johan
> 
> Well, the post was a bit incoherent because getting all this stuff working is. I was searching for ldc and ran across some web site that had only the sources(same for gdc).
> 
> The point of it all is that things seem to be a bit discombobulated and make D look bad.  Professions won't use D if it can't be used professionally(not that I'm a pro, just saying).
> 
> Why isn't there a proper binaries for ldc and gdc that work out of the box like dmd?  There used to be. What's up with all this arm-linux-genuabi crap? When one opens up the archive all the files are named that way too.  There is no explanation of what that means. Did some kid write this stuff in his basement or is this suppose to be serious? Do people think about the end user when creating this stuff or is it just a eureka moment "Lightbulb: Lets create some spaghetti!".
> 
> I would have thought things would have gotten easier and more logical but that doesn't seem to be the case.
> 
> 

On Saturday, 11 June 2016 at 16:04:45 UTC, Christophe Meessen wrote:
> Real professionals won't have difficulties to find binaries for ldc: https://github.com/ldc-developers/ldc/releases
>

They also don't waste their time posting asinine comments.

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.