www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - BindBC Updates: new loader function, SDL_net, streamlined SDL_*

reply Mike Parker <aldacron gmail.com> writes:
I've recently implemented some improvements centered on 
bindbc-sdl.

== New Loader Function

I've added a function to bindbc-loader (on Windows only) to allow 
adding a single path to the default DLL search path. This is to 
solve the problem that some of the SDL satellite libraries would 
fail to load when placed in a directory outside of the search 
path, such as a ./libs subdirectory.

The problem is that SDL loads its dependencies dynamically. So 
when a bindbc user would load a lib with a custom path, e.g., 
`loadSDLImage("libs\\SDL2_image.dll")`, the system loader would 
find that DLL just fine, but then when it in turn attempted to 
load a dependency like libpng, the system loader would search the 
DLL search path and *not* the libs subdirectory, thereby causing 
a failure.

Now you can do this:

```
version(Windows) setCustomLoaderSearchPath("libs");

if(loadSDL() < sdlSupport) { /* handle error */ }
if(loadSDL_Image() < sdlImageSupport) { /* handle error */ }

// Give SDL_image a chance to load libpng and libjpeg (it loads 
them lazily
// when the corresponding flags are passed to IMG_Init.
auto flags = IMG_INIT_PNG | IMG_INIT_JPEG;
if(IMG_Init(flags) != flags) { /* handle error */ }

// Now reset the default loader search path
version(Windows) setCustomLoaderSearchPath(null);
```

It's up to the caller to ensure the path is valid. For example, 
if the executable is run from a different directory, then "libs" 
will not be relative to the current working directory. 
`SDL_GetBasePath` can help there:

https://wiki.libsdl.org/SDL_GetBasePath?highlight=%28%5CbCategoryFilesystem%5Cb%29%7C%28CategoryEnum%29%7C%28CategoryStruct%29

I'm unaware of any issues with other libraries BindBC binds to, 
but if they do arise, this will solve those, too.

== SDL_net

I didn't initially port SDL_net over because I didn't think 
anyone was using it. I was waiting for someone to request it. 
Someone did. It's a small API, so it took a matter of minutes to 
complete.

== Streamlined SDL_* version identifiers

Previously, the SDL satellite library bindings could be enabled 
with e.g., `BindSDL_Image`, `BindSDL_TTF`, etc. That would enable 
the lowest supported version of the library. To enable a more 
recent version, an additional identifier was required 
(`SDL_Image_205`, `SDL_TTF_2014`). That's just dumb. Now, only 
one identifier is required, e.g., `SDL_Image_205` will do the 
trick by itself now. `SDL_Image` is equivalent to the 
`SDL_Image_200`. The old approach is still supported, though, so 
current build configs should continue to work without change.

See the loader documentation for details on the new function:

https://github.com/BindBC/bindbc-loader

There's also a bit about it in the bindbc-sdl documentation, 
along with the details about the approach to version identifiers.

https://github.com/BindBC/bindbc-sdl/blob/master/README.md

I've got some bigger packages to port over from Derelict yet (the 
OpenCL binding, for example). I've also had a request to include 
support for SDL's thread/mutex API so folks using DasBetterC can 
have access to it. That's all in the pipeline. Going forward, I 
plan to devote a handful of hours one day a week to bindbc until 
I've implemented everything on my task list, so it will get done 
sooner rather than later.
May 13
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Wednesday, 13 May 2020 at 14:39:13 UTC, Mike Parker wrote:

 It's up to the caller to ensure the path is valid. For example, 
 if the executable is run from a different directory, then 
 "libs" will not be relative to the current working directory. 
 `SDL_GetBasePath` can help there:

 https://wiki.libsdl.org/SDL_GetBasePath?highlight=%28%5CbCategoryFilesystem%5Cb%29%7C%28CategoryEnum%29%7C%28CategoryStruct%29
Well, duh. I put the cart before the horse on that one. SDL2.dll is going to be in the same subdirectory since all the others depend on it and will fail to load if it isn't there (they don't load it dynamically, of course). Working with args[0] or, since this is a Windows-only thing, calling the Win32 API directly (GetModuleFileName, IIRC) will get you there.
May 13
prev sibling next sibling parent reply Claude <claudemr live.fr> writes:
On Wednesday, 13 May 2020 at 14:39:13 UTC, Mike Parker wrote:
 I've recently implemented some improvements centered on 
 bindbc-sdl.
As a user of BindBC (and former Derelict), I really enjoy using those binding libraries. It's some great work, thanks.
May 14
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 14 May 2020 at 09:55:15 UTC, Claude wrote:

 As a user of BindBC (and former Derelict), I really enjoy using 
 those binding libraries. It's some great work, thanks.
Thanks!
May 16
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Wednesday, 13 May 2020 at 14:39:13 UTC, Mike Parker wrote:
 I've recently implemented some improvements centered on 
 bindbc-sdl.

 [...]
A little bit off topic. I wondered whether it is possible to combine dpp and bindbc. Maybe a separate Tool which creates a bindbc packages based on dpp output or even integrates into dpp? Did you already considered s.th. like that? Kind regards Andre
May 16
parent Mike Parker <aldacron gmail.com> writes:
On Saturday, 16 May 2020 at 09:00:25 UTC, Andre Pany wrote:

 A little bit off topic. I wondered whether it is possible to 
 combine dpp and bindbc. Maybe a separate Tool which creates a 
 bindbc packages based on dpp output or even integrates into dpp?

 Did you already considered s.th. like that?
Hasn't even crossed my mind. My first thought is that I don't see it as a good fit. Although all of my bindings follow a similar pattern, there are details specific to some of the libraries that led me to break the pattern. This arises mostly in the way different libraries handle their release versioning. Given dpp's use case, I don't see it as a generator of bindings that cover multiple library versions.
May 16
prev sibling parent reply Daniel C <dcrep rep.com> writes:
Can this library be used in a 64-bit build?  I only see the one 
lib, and was curious if the function definitions make any 
assumptions about argument size or stack configuration etc.
May 21
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 22/05/2020 12:21 PM, Daniel C wrote:
 Can this library be used in a 64-bit build?  I only see the one lib, and 
 was curious if the function definitions make any assumptions about 
 argument size or stack configuration etc.
There are no binary files provided in the bindbc-sdl repository. https://github.com/BindBC/bindbc-sdl It is a binding, it should match 1:1 definition wise to the C definition.
May 21
parent reply Daniel C <dcrep rep.com> writes:
 There are no binary files provided in the bindbc-sdl repository.

 https://github.com/BindBC/bindbc-sdl

 It is a binding, it should match 1:1 definition wise to the C 
 definition.
There is a library file included in the dub repository download: https://code.dlang.org/packages/bindbc-sdl 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. Oddly, when I use dub to compile the library file for bindbc-sdl, when I include that library file during linking it causes an error that it's not a valid library file... even though it was created with dub + dmd? Some odd things going on. I'm on Windows 7 x64 btw Thanks
May 22
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 22 May 2020 at 22:20:55 UTC, Daniel C wrote:

 There is a library file included in the dub repository 
 download: https://code.dlang.org/packages/bindbc-sdl
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.
 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?
 Oddly, when I use dub to compile the library file for 
 bindbc-sdl, when I include that library file during linking it 
 causes an error that it's not a valid library file... even 
 though it was created with dub + dmd?  Some odd things going 
 on.  I'm on Windows 7 x64 btw
Are you building it separately from your app? Or is it a dependency in your app's dub configuration? Please provide the commands you are using and the errors you are seeing. Then I can have an idea of what's going on.
May 22
parent reply Daniel C <dcrep rep.com> writes:
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.
May 22
next sibling parent reply Daniel C <dcrep rep.com> writes:
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.
May 22
parent reply Mike Parker <aldacron gmail.com> writes:
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-li path?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.
May 22
parent reply Daniel C <dcrep rep.com> writes:
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-li
path?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.
May 23
parent reply Daniel C <dcrep rep.com> writes:
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
May 23
parent reply Mike Parker <aldacron gmail.com> writes:
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.
May 23
parent reply Daniel C <dcrep rep.com> writes:
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 ;-)
May 23
parent Mike Parker <aldacron gmail.com> writes:
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!
May 24
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
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.
May 22
parent Daniel C <dcrep rep.com> writes:
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!
May 23