On Saturday, 23 May 2020 at 01:23:38 UTC, Mike Parker wrote:
> What download are you referring to? I don't have any library files in the git repository, and I don't know of any downloads from the duo repository.

Huh.. I'm not sure, it must have gotten there when I dub'd something lol.  Sorry

>> Also, when setting it to static compile, it complains during linking there are missing functions, even though I've already added the appropriate SDL library files.
>
> What are the missing symbols?

This is what I'm getting:
 Error 42: Symbol Undefined __D6bindbc3sdl4bind9sdlevents9SDL_Event6__initZ

> Are you building it separately from your app? Or is it a dependency in your app's dub configuration?

I did build it using dub from the downloaded folder, but I suppose that was pointless as the .lib file that's generated isn't even recognized.

I'm building my app without dub.  I've now put all the source files into the same folder as my project and I'm still seeing the same undefined symbol issue.

>
> Please provide the commands you are using and the errors you are seeing. Then I can have an idea of what's going on.

dmd.exe sdl_bindbc_test.d -g -m32 -w -debug -version=BindSDL_Static -version=SDL_2012 -version=SDL_Image_205 SDL2.lib SDL2_image.lib

Honestly it could be something I'm missing.  I saw the "-betterC" option in the documentation, but I assumed that my entire app would need to use -betterC so I avoided it.

Apologies if it's something dumb I'm overlooking.

On Saturday, 23 May 2020 at 03:25:12 UTC, Daniel C wrote:
> I'm building my app without dub.  I've now put all the source files into the same folder as my project and I'm still seeing the same undefined symbol issue.

I should say, I put the bindbc library into a subfolder. So it's like this:

project/bindbc/sdl/bind

The SDL lib files are in the same folder with the source, primarily because the LIB environment variable was being ignored by the compiler/linker.

On Saturday, 23 May 2020 at 03:25:12 UTC, Daniel C wrote:
> On Saturday, 23 May 2020 at 01:23:38 UTC, Mike Parker wrote:
>> What download are you referring to? I don't have any library files in the git repository, and I don't know of any downloads from the duo repository.
>
> Huh.. I'm not sure, it must have gotten there when I dub'd something lol.  Sorry

It gets there when you build it :-)

>
>>> Also, when setting it to static compile, it complains during linking there are missing functions, even though I've already added the appropriate SDL library files.
>>
>> What are the missing symbols?
>
> This is what I'm getting:
>  Error 42: Symbol Undefined __D6bindbc3sdl4bind9sdlevents9SDL_Event6__initZ

This isn't a symbol from the SDL library. It's a D symbol from the binding.

>
>> Are you building it separately from your app? Or is it a dependency in your app's dub configuration?
>
> I did build it using dub from the downloaded folder, but I suppose that was pointless as the .lib file that's generated isn't even recognized.
>
> I'm building my app without dub.  I've now put all the source files into the same folder as my project and I'm still seeing the same undefined symbol issue.
>
>>
>> Please provide the commands you are using and the errors you are seeing. Then I can have an idea of what's going on.
>
> dmd.exe sdl_bindbc_test.d -g -m32 -w -debug -version=BindSDL_Static -version=SDL_2012 -version=SDL_Image_205 SDL2.lib SDL2_image.lib

You didn't link with the bindbc-sdl library. But a couple of points about that -m32 option:

1. On Windows, DMD always builds with -m32 by default, so you don't need to specify it.
2. It means you're using the default OPTLINK linker which requires object files in the OMF format.
3. The COFF format is more common in the Windows ecosystem, which the -m32mscoff and -m64 options will cause to be generated
4. Unlike DMD, dub will use the system architecture on Windows for the default build, meaning on 64-bit Windows it will automatically pass -m64 to DMD.

>
> Honestly it could be something I'm missing.  I saw the "-betterC" option in the documentation, but I assumed that my entire app would need to use -betterC so I avoided it.

No. You can link to betterC libraries with a normal D app.

>
> Apologies if it's something dumb I'm overlooking.

Essentially, the bindbc-sdl library you built is invalid because dub built it with -m64 (unless you explicitly passed -ax86 on the dub command line) and you built your app with -m32, giving you both an architecture mismatch and an object file format mismatch.

Then your dmd command is missing the bindbc-sdl library, hence the linker error.

On Saturday, 23 May 2020 at 03:29:44 UTC, Daniel C wrote:
> On Saturday, 23 May 2020 at 03:25:12 UTC, Daniel C wrote:
>> I'm building my app without dub.  I've now put all the source files into the same folder as my project and I'm still seeing the same undefined symbol issue.
>
> I should say, I put the bindbc library into a subfolder. So it's like this:
>
> project/bindbc/sdl/bind
>
> The SDL lib files are in the same folder with the source, primarily because the LIB environment variable was being ignored by the compiler/linker.

I suggest you create project/lib and drop the SDL libraries there along with the bindbc-sdl library and pass the path to the linker. Since you should be using the MS linker (see below), it expects the /LIBPATH option (https://docs.microsoft.com/en-us/cpp/build/reference/libpath-additional-libpath?view=vs-2019), which you can add to your dmd commandline as `-L/LIBPATH:lib`. Of course, that's assuming you've got the Microsoft Build Tools installed either independently or as part of a Visual Studio installation. If not, you'll be using the LLVM linker that ships with DMD. I believe in that case it should be `-L-Llib`.

If you really want 32-bit and to statically link with the SDL import libraries, I strongly recommend you use the -m32mscoff dmd options (and the corresponding -ax86_mscoff dub option). The SDL libraries are distributed as COFF, not OMF, so using OPTLINK would require converting the lib files to OMF first.

On Saturday, 23 May 2020 at 03:55:33 UTC, Mike Parker wrote:
> On Saturday, 23 May 2020 at 03:25:12 UTC, Daniel C wrote:
>>
>> This is what I'm getting:
>>  Error 42: Symbol Undefined __D6bindbc3sdl4bind9sdlevents9SDL_Event6__initZ
>
> This isn't a symbol from the SDL library. It's a D symbol from the binding.

I figured as much, that's why I tried to link against the bindbc-sdl library at first (which then gave me the invalid library file error).  I removed it from the line I posted to get that message to reappear.

> You didn't link with the bindbc-sdl library. But a couple of points about that -m32 option:
>
> 1. On Windows, DMD always builds with -m32 by default, so you don't need to specify it.
> 2. It means you're using the default OPTLINK linker which requires object files in the OMF format.
> 3. The COFF format is more common in the Windows ecosystem, which the -m32mscoff and -m64 options will cause to be generated
> 4. Unlike DMD, dub will use the system architecture on Windows for the default build, meaning on 64-bit Windows it will automatically pass -m64 to DMD.

Ugh, I remember running into build issues when I gave D a shot a few years ago.  There's a lot of options and specifics that aren't very well documented, or at the very least confusing.  In the case of Dub, it felt to me like some black box that wasn't clear as to what it was doing (even having tried to read the documentation a few times).  I felt more in control and aware of what was going on with dmd but lol, again I was missing something.

> No. You can link to betterC libraries with a normal D app.

Oh, that's good news.  I'll pass that option next time.. or actually - I'm not sure what will change in the generated library?

> Essentially, the bindbc-sdl library you built is invalid because dub built it with -m64 (unless you explicitly passed -ax86 on the dub command line) and you built your app with -m32, giving you both an architecture mismatch and an object file format mismatch.
>
> Then your dmd command is missing the bindbc-sdl library, hence the linker error.

Ah.  Dub did do something mischievous after all ;-)  And thanks, yeah I'll add the bindbc-sdl library back in after I get my command lines straight.  More experimentation ahead.

Thanks so much for your help!

On Saturday, 23 May 2020 at 04:07:35 UTC, Mike Parker wrote:
> I suggest you create project/lib and drop the SDL libraries there along with the bindbc-sdl library and pass the path to the linker. Since you should be using the MS linker (see below), it expects the /LIBPATH option (https://docs.microsoft.com/en-us/cpp/build/reference/libpath-additional-libpath?view=vs-2019), which you can add to your dmd commandline as `-L/LIBPATH:lib`. Of course, that's assuming you've got the Microsoft Build Tools installed either independently or as part of a Visual Studio installation. If not, you'll be using the LLVM linker that ships with DMD. I believe in that case it should be `-L-Llib`.
>
> If you really want 32-bit and to statically link with the SDL import libraries, I strongly recommend you use the -m32mscoff dmd options (and the corresponding -ax86_mscoff dub option). The SDL libraries are distributed as COFF, not OMF, so using OPTLINK would require converting the lib files to OMF first.

Thanks. I did have SDL in a project/lib folder and was trying to set LIB and then use -L and other options, but I suppose I borked that up as well.  Thanks again for the tips!  I'll be mucking around with it again later.

On Saturday, 23 May 2020 at 19:59:51 UTC, Daniel C wrote:
> I'll be mucking around with it again later.

Well, I'm having limited success.  I got 32-bit compile/run using basic -m32, and -m64 compiles but crashes lol.  Trying out 32-bit -m32mscoff with Microsoft Build Tools (2019) resulted in this mess:
phobos32mscoff.lib(runtime_c8b_76e.obj) : error LNK2001: unresolved external sym
bol _printf
phobos32mscoff.lib(parseoptions_d98_7cf.obj) : error LNK2001: unresolved externa
l symbol _printf
phobos32mscoff.lib(gc_244f_122.obj) : error LNK2001: unresolved external symbol
_printf
phobos32mscoff.lib(msvc_32mscoff.obj) : error LNK2001: unresolved external symbo
l __vsnprintf
phobos32mscoff.lib(parseoptions_d93_21b.obj) : error LNK2001: unresolved externa
l symbol _sscanf

Frustrating!  I don't even know where to go for help with that stuff.  Through experimentation, I was able to compile with older Visual C++ 2010 tools, but I'd rather not be using 10 year old tech.

Maybe this wasn't the time for me to come back lol

On Sunday, 24 May 2020 at 04:16:10 UTC, Daniel C wrote:
> On Saturday, 23 May 2020 at 19:59:51 UTC, Daniel C wrote:
>> I'll be mucking around with it again later.
>
> Well, I'm having limited success.  I got 32-bit compile/run using basic -m32, and -m64 compiles but crashes lol.  Trying out 32-bit -m32mscoff with Microsoft Build Tools (2019) resulted in this mess:
> phobos32mscoff.lib(runtime_c8b_76e.obj) : error LNK2001: unresolved external sym
> bol _printf
> phobos32mscoff.lib(parseoptions_d98_7cf.obj) : error LNK2001: unresolved externa
> l symbol _printf
> phobos32mscoff.lib(gc_244f_122.obj) : error LNK2001: unresolved external symbol
> _printf
> phobos32mscoff.lib(msvc_32mscoff.obj) : error LNK2001: unresolved external symbo
> l __vsnprintf
> phobos32mscoff.lib(parseoptions_d93_21b.obj) : error LNK2001: unresolved externa
> l symbol _sscanf
>
> Frustrating!  I don't even know where to go for help with that stuff.  Through experimentation, I was able to compile with older Visual C++ 2010 tools, but I'd rather not be using 10 year old tech.

There should be no need to revert to VS 2010. These errors indicate that something in your build process or setup is borked.

Have you tried building your app with dub and using bindbc-sdl as a dependency rather than doing it separately DMD? This way, you can ensure that everything is being compiled with the same options and the linker is getting the correct libraries.

>
> Maybe this wasn't the time for me to come back lol

I would say it's generally much easier to build D projects these days than it ever has been. We just need to figure out where you're going wrong.

On Sunday, 24 May 2020 at 05:15:19 UTC, Mike Parker wrote:
> On Sunday, 24 May 2020 at 04:16:10 UTC, Daniel C wrote:
>> On Saturday, 23 May 2020 at 19:59:51 UTC, Daniel C wrote:
>
> There should be no need to revert to VS 2010. These errors indicate that something in your build process or setup is borked.
>
> Have you tried building your app with dub and using bindbc-sdl as a dependency rather than doing it separately DMD? This way, you can ensure that everything is being compiled with the same options and the linker is getting the correct libraries.

I figured it out by going through the changelog for the compiler.  From "Change Log: 2.069.0" @ https://dlang.org/changelog/2.069.0.html#link-against-vs2015

"If you don't use dmd for linking, make sure to add legacy_stdio_definitions.lib to your command line when linking against the VS2015 runtime."

Adding legacy_stdio_definitions.lib fixed that last problem.  The 64-bit build is working as well.. I had mistakenly put the wrong DLL alongside it *facepalm*.  It's using the default linker for 64-bit though, so I'll need to try with the Visual Studio linker. Now that I've figured out the rest, I think it should be trivial though.

Obviously the legacy_stdio_definitions.lib file needs to be documented somewhere on this site other than on a changelog.

I will probably use dub for projects in the future, but I wanted a quick compilation option for building single-file programs without the extra setup and structure dub entails.

Anyway, thanks for your help Mike! Without it I may have given up on D for another year or so ;-)

On Sunday, 24 May 2020 at 06:39:27 UTC, Daniel C wrote:


>
> "If you don't use dmd for linking, make sure to add legacy_stdio_definitions.lib to your command line when linking against the VS2015 runtime."

Good find. If I was ever aware of that, I had forgotten about it.

>
> Anyway, thanks for your help Mike! Without it I may have given up on D for another year or so ;-)

Glad I could help!