Is it possible to use C header-only libs from D?

In C, I would need to do this:

#define STB_DS_IMPLEMENTATION
#include "stb_ds.h"

The definition must be done in a single C file before including the h file.

I tried this in D:

enum STB_DS_IMPLEMENTATION = 1;
import stb_ds;

But it doesn't work. Any suggestions? Perhaps using an intermediate C file to do this would work, but I wanted to know if D can do it.

On Monday, 8 January 2024 at 18:53:47 UTC, Renato wrote:

#define STB_DS_IMPLEMENTATION
#include "stb_ds.h"

enum STB_DS_IMPLEMENTATION = 1;
import stb_ds;

Without knowing the specifics of what you're trying to do, this automatic translation of C headers to D might be what you want:

https://forum.dlang.org/post/ugvc3o$5t3$1@digitalmars.com

The way "header-only" is usually used suggests you should change the file extension to .c and compile it directly.

On Monday, 8 January 2024 at 18:53:47 UTC, Renato wrote:

Yes, your best options are either:

• rename the .h to .c and edit it so the STB_DS_IMPLEMENTATION check passes or is removed.
• create a C file with what you already wrote:

#define STB_DS_IMPLEMENTATION
#include "stb_ds.h"

And import that.

Importing .h files from d files isn't supported yet because of a dispute with the lookup priority:

https://issues.dlang.org/show_bug.cgi?id=23479
https://issues.dlang.org/show_bug.cgi?id=23547

On Monday, 8 January 2024 at 19:17:06 UTC, Lance Bachmeier wrote:

#define STB_DS_IMPLEMENTATION
#include "stb_ds.h"

enum STB_DS_IMPLEMENTATION = 1;
import stb_ds;

I am trying to use a header-only C library. A h file from this project, specifically: https://github.com/nothings/stb

That doesn't work without the #define, as I mentioned. Header libraries like this are designed to only be included once, given that they have impl code, so they rely on the C file defining a variable to explicitly "enable" the impl code to be included.

Based on that thread you've linked, I tried generating a di file from a basic C file that just has the define and include:

#define STB_DS_IMPLEMENTATION
#include "stb_ds.h"

But that gets me a seg fault with DMD:

▶ dmd -c import_stb_ds.c -Hf=stb_ds.di
[1]    73719 segmentation fault  dmd -c import_stb_ds.c -Hf=stb_ds.di
(dmd-2.106.1)

LDC also does:

▶ ldc2 -c import_stb_ds.c -Hf=stb_ds.di
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  ldc2                     0x000000010f860d87 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 39
1  ldc2                     0x000000010f85fce6 llvm::sys::RunSignalHandlers() + 198
2  ldc2                     0x000000010f8613e0 SignalHandler(int) + 288
3  libsystem_platform.dylib 0x00007ff8115bf37d _sigtramp + 29
4  libsystem_c.dylib        0x00007ff81143772b __sfvwrite + 355
[1]    73787 segmentation fault  ldc2 -c import_stb_ds.c -Hf=stb_ds.di
(ldc-1.35.0)

Should I report a bug?

On Monday, 8 January 2024 at 21:04:10 UTC, Dennis wrote:

#define STB_DS_IMPLEMENTATION
#include "stb_ds.h"

You answered almost at the same time as I sent my previous answer, so I hadn't seen your comment, but I tried exactly that! Which gives a seg fault.

I also tried just importing this little C file, but then no symbols from the h file are found at all. Kind of interesting, as if I just write the code using the library in the C file itself, that works fine.

Ah, too bad. Anyway, I was just playing around... disappointing that it doesn't work but I don't really need this for now.

On Monday, 8 January 2024 at 21:56:10 UTC, Renato wrote:

Looks like there's a bug with the -H switch:
https://issues.dlang.org/show_bug.cgi?id=24326

But that shouldn't be necessary, you should just be able to import the c file.

That's weird, I'll see if I can reproduce this.

On Monday, 8 January 2024 at 21:56:10 UTC, Renato wrote:

Disappointing I know, but there is the workaround of creating a C file and included the h file in it. Not elegant though.

On Monday, 8 January 2024 at 23:00:02 UTC, Dennis wrote:

That's the bug that is affecting me almost certainly because the library I'm using does have an anonymous enum in it, which causes that bug when parsing h files.

What I don't understand, though, is that the bug was fixed more than one year ago, there was some regression found that forced the bug fix to be reverted, but then it just... stayed that way??