www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ImportC and #include files

reply Walter Bright <newshound2 digitalmars.com> writes:
It turns out that every platform we support has "Standard" .h files that won't 
compile with Standard C11. They all rely on multiple extensions, each platform 
with a different set of reliances (usually unnecessary).

We cannot fix those .h files, we can only fix #ImportC so they work. There has 
been considerable progress on that front.

But I could use some help.

Try using ImportC on various popular C .h files on your platform. For the ones 
that fail to compile, please find the offending few lines of code and post them 
to bugzilla. (Just the error message and the name of the .h file is not enough, 
several of this sort have been posted to bugzilla, but sadly I can do nothing 
with them because I don't have those .h files.)

Of particular interest would be the Deimos project, as it would be good to make 
Deimos obsolete.

Thanks! Every .h file we can make work makes ImportC that much more useful.
It's 
a high leverage activity for time invested.
Apr 27 2023
next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 27 April 2023 at 20:16:32 UTC, Walter Bright wrote:


 Try using ImportC on various popular C .h files on your 
 platform. For the ones that fail to compile, please find the 
 offending few lines of code and post them to bugzilla. (Just 
 the error message and the name of the .h file is not enough, 
 several of this sort have been posted to bugzilla, but sadly I 
 can do nothing with them because I don't have those .h files.)


Looks like you've made a lot of progress the last few months. I 
was going to file some bug reports to help you out. I tested DMD 
(latest commit on Github) with a couple of C programs that were 
not close to compiling in late December. Unfortunately there were 
no issues today. There was no difference when compiling and 
running using dmd or gcc.
Apr 28 2023
next sibling parent reply bachmeier <no spam.net> writes:
On Friday, 28 April 2023 at 14:25:39 UTC, bachmeier wrote:

 On Thursday, 27 April 2023 at 20:16:32 UTC, Walter Bright wrote:


 Try using ImportC on various popular C .h files on your 
 platform. For the ones that fail to compile, please find the 
 offending few lines of code and post them to bugzilla. (Just 
 the error message and the name of the .h file is not enough, 
 several of this sort have been posted to bugzilla, but sadly I 
 can do nothing with them because I don't have those .h files.)


 Looks like you've made a lot of progress the last few months. I 
 was going to file some bug reports to help you out. I tested 
 DMD (latest commit on Github) with a couple of C programs that 
 were not close to compiling in late December. Unfortunately 
 there were no issues today. There was no difference when 
 compiling and running using dmd or gcc.


In case anyone is curious about the details, I compiled test 
programs in the GNU Scientific Library. One was for function 
minimization and the other random number generation.

Compiling with gcc:

```
gcc test.c -I../../gsl-2.7.1 -I/usr/include 
-L/usr/lib/x86_64-linux-gnu/ -lgsl -lgslcblas -lm
```

Compiling with dmd:

```
dmd test.c -P-I../../gsl-2.7.1 -I/usr/include 
-I/usr/lib/x86_64-linux-gnu/ -L-lgsl -L-lgslcblas -L-lm
```
Apr 28 2023
next sibling parent reply some_d_user <some thing.com> writes:
On Friday, 28 April 2023 at 14:35:25 UTC, bachmeier wrote:

 On Friday, 28 April 2023 at 14:25:39 UTC, bachmeier wrote:

 On Thursday, 27 April 2023 at 20:16:32 UTC, Walter Bright 
 wrote:


 Try using ImportC on various popular C .h files on your 
 platform. For the ones that fail to compile, please find the 
 offending few lines of code and post them to bugzilla. (Just 
 the error message and the name of the .h file is not enough, 
 several of this sort have been posted to bugzilla, but sadly 
 I can do nothing with them because I don't have those .h 
 files.)


 Looks like you've made a lot of progress the last few months. 
 I was going to file some bug reports to help you out. I tested 
 DMD (latest commit on Github) with a couple of C programs that 
 were not close to compiling in late December. Unfortunately 
 there were no issues today. There was no difference when 
 compiling and running using dmd or gcc.


 In case anyone is curious about the details, I compiled test 
 programs in the GNU Scientific Library. One was for function 
 minimization and the other random number generation.

 Compiling with gcc:

 ```
 gcc test.c -I../../gsl-2.7.1 -I/usr/include 
 -L/usr/lib/x86_64-linux-gnu/ -lgsl -lgslcblas -lm
 ```

 Compiling with dmd:

 ```
 dmd test.c -P-I../../gsl-2.7.1 -I/usr/include 
 -I/usr/lib/x86_64-linux-gnu/ -L-lgsl -L-lgslcblas -L-lm
 ```


Appearently I'm not the only one interested in mathematical 
optimization ;)
I tried to build one of the examples of 
https://github.com/scipopt/scip (linking against a gcc compiled 
binary) and dmd screwed up on "assert(scip != NULL);". I tracked 
that down  to https://issues.dlang.org/show_bug.cgi?id=23864 
which seems to be caused by my system headers.
Apr 28 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/28/2023 8:11 AM, some_d_user wrote:

 I tried to build one of the examples of https://github.com/scipopt/scip
(linking 
 against a gcc compiled binary) and dmd screwed up on "assert(scip != NULL);".
I 
 tracked that down  to https://issues.dlang.org/show_bug.cgi?id=23864 which
seems 
 to be caused by my system headers.



Thanks! I'll check it out.
Apr 28 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/28/2023 12:03 PM, Walter Bright wrote:

 On 4/28/2023 8:11 AM, some_d_user wrote:

 I tried to build one of the examples of https://github.com/scipopt/scip 
 (linking against a gcc compiled binary) and dmd screwed up on "assert(scip != 
 NULL);". I tracked that down  to 
 https://issues.dlang.org/show_bug.cgi?id=23864 which seems to be caused by my 
 system headers.


 
 
 Thanks! I'll check it out.


I have some questions for you in the bug report.
Apr 29 2023
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 28 April 2023 at 14:35:25 UTC, bachmeier wrote:

 [snip]
 Compiling with dmd:

 ```
 dmd test.c -P-I../../gsl-2.7.1 -I/usr/include 
 -I/usr/lib/x86_64-linux-gnu/ -L-lgsl -L-lgslcblas -L-lm
 ```


Alright, I built dmd from source on WSL2. I was able to get a 
simple importc program working, but then I got a little stuck 
when I try to make it a little more complicated.

What I want to do is the equivalent of `#include <math.h>` from 
C, but in a D file. I tried using `import math;` with a small 
program that uses it and compiled `dmd file.d -L-lm` but I get a 
message that it can't find the math module.

It seemed to do a bit better when I renamed the file to have a .c 
ending, but then I would have to put the code back in C terms so 
I get errors related to that. When I fix those and replace the 
`import math;` with the include, then it works. But this is just 
compiling the C code with a D compiler. I want to use the C code 
in a D program.
May 04 2023
parent reply bachmeier <no spam.net> writes:
On Thursday, 4 May 2023 at 13:34:25 UTC, jmh530 wrote:

 On Friday, 28 April 2023 at 14:35:25 UTC, bachmeier wrote:

 [snip]
 Compiling with dmd:

 ```
 dmd test.c -P-I../../gsl-2.7.1 -I/usr/include 
 -I/usr/lib/x86_64-linux-gnu/ -L-lgsl -L-lgslcblas -L-lm
 ```


 Alright, I built dmd from source on WSL2. I was able to get a 
 simple importc program working, but then I got a little stuck 
 when I try to make it a little more complicated.

 What I want to do is the equivalent of `#include <math.h>` from 
 C, but in a D file. I tried using `import math;` with a small 
 program that uses it and compiled `dmd file.d -L-lm` but I get 
 a message that it can't find the math module.

 It seemed to do a bit better when I renamed the file to have a 
 .c ending, but then I would have to put the code back in C 
 terms so I get errors related to that. When I fix those and 
 replace the `import math;` with the include, then it works. But 
 this is just compiling the C code with a D compiler. I want to 
 use the C code in a D program.


It would help to have your code. My examples using the R 
standalone math library are somewhat more involved by the nature 
of that library.

Here's a file test.d:

```
import qnorm;
import std.stdio;

void main() {
   writeln(Rf_qnorm5(0.3,1.2, 0.8, 0, 0));
}
```

The equivalent R code is `qnorm(0.3, 1.2, 0.8, FALSE)`.

The `import qnorm` line tells DMD to pull in the code from 
qnorm.c in that same directory. I don't need to add qnorm.c in 
the compilation command, which is

```
dmd test.d -P-I. -P-I../gnuwin32/fixed/h -P-I../include 
-L/usr/lib/libR.so
```

Is DMD doing something with qnorm.c? I don't know, but if I 
comment out `import qnorm;`, I get the error message

```
test.d(5): Error: undefined identifier `Rf_qnorm5`
```

so I assume it's working. Maybe I can come up with a simpler/more 
practical example without the complexity of this library. This is 
the first time ImportC has worked well enough for me to compile C 
files.
May 05 2023
next sibling parent reply bachmeier <no spam.net> writes:
On Friday, 5 May 2023 at 22:56:20 UTC, bachmeier wrote:


 Maybe I can come up with a simpler/more practical example 
 without the complexity of this library. This is the first time 
 ImportC has worked well enough for me to compile C files.


Here's a simpler example using math.h that works for me:

https://gist.github.com/bachmeil/6da28f934454864b7ddf80e2d1eaa5e5
May 05 2023
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 5 May 2023 at 23:05:02 UTC, bachmeier wrote:

 On Friday, 5 May 2023 at 22:56:20 UTC, bachmeier wrote:


 Maybe I can come up with a simpler/more practical example 
 without the complexity of this library. This is the first time 
 ImportC has worked well enough for me to compile C files.


 Here's a simpler example using math.h that works for me:

 https://gist.github.com/bachmeil/6da28f934454864b7ddf80e2d1eaa5e5


I’m afk this weekend, but I didn’t have a .c file that included 
the math header. I just wanted to use the c header directly in 
the d file. I want to try having a blank .c file that includes 
the math header and see if I can use that with D.
May 05 2023
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/5/2023 5:35 PM, jmh530 wrote:

 I want to try having a 
 blank .c file that includes the math header and see if I can use that with D.


That should work.
May 05 2023
prev sibling parent reply bachmeier <no spam.net> writes:
On Saturday, 6 May 2023 at 00:35:46 UTC, jmh530 wrote:

 On Friday, 5 May 2023 at 23:05:02 UTC, bachmeier wrote:

 On Friday, 5 May 2023 at 22:56:20 UTC, bachmeier wrote:


 Maybe I can come up with a simpler/more practical example 
 without the complexity of this library. This is the first 
 time ImportC has worked well enough for me to compile C files.


 Here's a simpler example using math.h that works for me:

 https://gist.github.com/bachmeil/6da28f934454864b7ddf80e2d1eaa5e5


 I’m afk this weekend, but I didn’t have a .c file that included 
 the math header. I just wanted to use the c header directly in 
 the d file. I want to try having a blank .c file that includes 
 the math header and see if I can use that with D.


I updated the gist so the c file contains only `#include 
<math.h>`. It works.
May 05 2023
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Saturday, 6 May 2023 at 01:07:15 UTC, bachmeier wrote:

 On Saturday, 6 May 2023 at 00:35:46 UTC, jmh530 wrote:

 On Friday, 5 May 2023 at 23:05:02 UTC, bachmeier wrote:

 On Friday, 5 May 2023 at 22:56:20 UTC, bachmeier wrote:


 [...]


 Here's a simpler example using math.h that works for me:

 https://gist.github.com/bachmeil/6da28f934454864b7ddf80e2d1eaa5e5


 I’m afk this weekend, but I didn’t have a .c file that 
 included the math header. I just wanted to use the c header 
 directly in the d file. I want to try having a blank .c file 
 that includes the math header and see if I can use that with D.


 I updated the gist so the c file contains only `#include 
 <math.h>`. It works.


Thanks!
May 06 2023
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Saturday, 6 May 2023 at 01:07:15 UTC, bachmeier wrote:

 On Saturday, 6 May 2023 at 00:35:46 UTC, jmh530 wrote:

 On Friday, 5 May 2023 at 23:05:02 UTC, bachmeier wrote:

 On Friday, 5 May 2023 at 22:56:20 UTC, bachmeier wrote:


 Maybe I can come up with a simpler/more practical example 
 without the complexity of this library. This is the first 
 time ImportC has worked well enough for me to compile C 
 files.


 Here's a simpler example using math.h that works for me:

 https://gist.github.com/bachmeil/6da28f934454864b7ddf80e2d1eaa5e5


 I’m afk this weekend, but I didn’t have a .c file that 
 included the math header. I just wanted to use the c header 
 directly in the d file. I want to try having a blank .c file 
 that includes the math header and see if I can use that with D.


 I updated the gist so the c file contains only `#include 
 <math.h>`. It works.


I was able to get nlopt's tutorial example working with importC. 
I can write a bit more up later.

The only thing that I wasn't able to get working was using the 
HUGE_VAL macro in math.h. Would anyone else be able to confirm if 
they are able to get that working?
May 08 2023
next sibling parent reply bachmeier <no spam.net> writes:
On Monday, 8 May 2023 at 13:22:44 UTC, jmh530 wrote:


 I was able to get nlopt's tutorial example working with 
 importC. I can write a bit more up later.

 The only thing that I wasn't able to get working was using the 
 HUGE_VAL macro in math.h. Would anyone else be able to confirm 
 if they are able to get that working?


In the .c file or the .d file? If in the .d file, you'll need to 
use core.stdc.math.HUGE_VAL. If in the .c file, it's a bug.
May 08 2023
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 8 May 2023 at 14:36:10 UTC, bachmeier wrote:

 On Monday, 8 May 2023 at 13:22:44 UTC, jmh530 wrote:


 I was able to get nlopt's tutorial example working with 
 importC. I can write a bit more up later.

 The only thing that I wasn't able to get working was using the 
 HUGE_VAL macro in math.h. Would anyone else be able to confirm 
 if they are able to get that working?


 In the .c file or the .d file? If in the .d file, you'll need 
 to use core.stdc.math.HUGE_VAL. If in the .c file, it's a bug.


I was just trying out using it directly in the .d file without 
importing core.stdc.math. I am able to use HUGE_VAL in the .c 
file (so not a bug that way). The c math header should be setting 
HUGE_VAL based on a preprocessor macro (on WSL I assume it should 
run automatically). I was assuming that importC would re-write 
that to an enum that I could use directly in the D file, but the 
spec says that it doesn't support all uses of metaprogramming 
with these. You think that's what I'm running into?
May 08 2023
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 8 May 2023 at 15:34:32 UTC, jmh530 wrote:

 [snip]
 I was assuming that importC would re-write that to an enum that 
 I could use directly in the D file, but the spec says that it 
 doesn't support all uses of metaprogramming with these. You 
 think that's what I'm running into?


Hmm, I'm not sure how much sense that makes since I'm able to use 
it in the .c file...
May 08 2023
parent reply bachmeier <no spam.net> writes:
On Monday, 8 May 2023 at 15:50:09 UTC, jmh530 wrote:

 On Monday, 8 May 2023 at 15:34:32 UTC, jmh530 wrote:

 [snip]
 I was assuming that importC would re-write that to an enum 
 that I could use directly in the D file, but the spec says 
 that it doesn't support all uses of metaprogramming with 
 these. You think that's what I'm running into?


 Hmm, I'm not sure how much sense that makes since I'm able to 
 use it in the .c file...


To my knowledge, you're only able to use them in .c files. .d 
files aren't run through the preprocessor and I don't know of any 
way to access a C macro from D...but maybe I'm wrong. I've been 
using core.stdc.
May 08 2023
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 8 May 2023 at 15:57:01 UTC, bachmeier wrote:

 On Monday, 8 May 2023 at 15:50:09 UTC, jmh530 wrote:

 On Monday, 8 May 2023 at 15:34:32 UTC, jmh530 wrote:

 [snip]
 I was assuming that importC would re-write that to an enum 
 that I could use directly in the D file, but the spec says 
 that it doesn't support all uses of metaprogramming with 
 these. You think that's what I'm running into?


 Hmm, I'm not sure how much sense that makes since I'm able to 
 use it in the .c file...


 To my knowledge, you're only able to use them in .c files. .d 
 files aren't run through the preprocessor and I don't know of 
 any way to access a C macro from D...but maybe I'm wrong. I've 
 been using core.stdc.


If you have a simple #define in a .c file, you can access it from 
a .d file. I tried the importC spec example with `#define COLOR 
0x123456` getting re-written to `enum COLOR = 0x123456;` and it 
worked.

The HUGE_VAL macro is a little more complicated. It relies on #if 
and it calls some `__builtin_huge_val`. However, if I have 
`static double LARGE_VAL = HUGE_VAL` in the .c file, I was able 
to access LARGE_VAL in the .d file as expected. So the 
preprocessor is able to run, but maybe it's not creating the enum 
version due to the other macros going on.
May 08 2023
next sibling parent reply bachmeier <no spam.net> writes:
On Monday, 8 May 2023 at 17:29:38 UTC, jmh530 wrote:


 If you have a simple #define in a .c file, you can access it 
 from a .d file. I tried the importC spec example with `#define 
 COLOR 0x123456` getting re-written to `enum COLOR = 0x123456;` 
 and it worked.


That's useful to know. I was not aware.


 The HUGE_VAL macro is a little more complicated. It relies on 
 #if and it calls some `__builtin_huge_val`. However, if I have 
 `static double LARGE_VAL = HUGE_VAL` in the .c file, I was able 
 to access LARGE_VAL in the .d file as expected. So the 
 preprocessor is able to run, but maybe it's not creating the 
 enum version due to the other macros going on.


Looks like that's gcc:

https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fhuge_005fval

Probably requires an addition to importc.h, as has been done for 
several other cases already:

https://github.com/dlang/dmd/blob/master/druntime/src/importc.h#L79
May 08 2023
parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 8 May 2023 at 17:54:45 UTC, bachmeier wrote:

 On Monday, 8 May 2023 at 17:29:38 UTC, jmh530 wrote:


 [...]


 Looks like that's gcc:

 https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fhuge_005fval

 Probably requires an addition to importc.h, as has been done 
 for several other cases already:

 https://github.com/dlang/dmd/blob/master/druntime/src/importc.h#L79


Something like below might be worth adding
#define __builtin_huge_val double.infinity
#define __builtin_huge_valf float.infinity
#define __builtin_huge_vall real.infinity
#define __builtin_inf double.infinity
#define __builtin_inff float.infinity
#define __builtin_infl real.infinity
#define __builtin_nan double.nan
#define __builtin_nanf float.nan
#define __builtin_nanl real.nan

DRuntime implements HUGE_VAL this way, though some reference 
materials say that it behaves differently on machines that don't 
have infinity defined. So it's a bit legacy.

Here's a potentially incomplete list of some things that would 
need to be defined to cover most of the rest of core.stdc.math:
FP_ILOGB0
FP_ILOGBNAN
__builtin_signbit
__builtin_fpclassify
__builtin_isfinite
__builtin_isnormal
__builtin_isgreaterequal
__builtin_isless
__builtin_islessequal
__builtin_islessgreater
__builtin_isunordered
May 08 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Support for C macros being accessible to D code is very limited, pretty much 
just enums for constants.

I plan to improve this in the future, but it's what it is today.
May 08 2023
parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 8 May 2023 at 20:12:44 UTC, Walter Bright wrote:

 Support for C macros being accessible to D code is very 
 limited, pretty much just enums for constants.

 I plan to improve this in the future, but it's what it is today.


Cool.

What I was reporting above was mostly due to these missing 
builtins. I think some of the simple ones with #if were working 
otherwise.
May 08 2023
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 8 May 2023 at 13:22:44 UTC, jmh530 wrote:

 [snip
 I was able to get nlopt's tutorial example working with 
 importC. I can write a bit more up later.


For some more details, in case anyone is interested (and myself 
in case I forget and need to search for it in the future). I 
installed nlopt as a shared library to some random location (I 
had to use cmake to disable installation of some parts, like how 
it handles python). I started with the tutorial [1] and put 
together a C version of the example and compiled with gcc using
```
gcc cversion.c -w -lnlopt -lm -L/usr/local/nlopt/nlopt/build/ 
-Wl,-rpath=/usr/local/nlopt/nlopt/build/ -o myprogram
```
The -Wl,rpath is because I didn't install the shared library into 
a usual location for shared libraries. How to actually do this in 
practice depends on how you install it and whether to use shared 
or static libraries. Regardless, I think it is good to get the C 
version working first.

I then created two .c files one that just includes nlopt.h and 
another that just includes math.h (as bachmeier recommends) and 
adjusted the C version of the tutorial to a D version (see below) 
and compiled with

```d
dmd dversion.d math.c nlopt.c -of=dversion -L-lnlopt 
-L--rpath=/usr/local/nlopt/nlopt/build/
```

dversion.d
```d
import math;
import nlopt;

extern(C)
double myfunc(uint n, const double* x, double* grad, void* 
my_func_data)
{
     if (grad) {
         grad[0] = 0.0;
         grad[1] = 0.5 / sqrt(x[1]);
     }
     return sqrt(x[1]);
}

struct my_constraint_data
{
     double a, b;
}

extern(C)
double myconstraint(uint n, const double* x, double* grad, void* 
data)
{
     my_constraint_data* d = cast(my_constraint_data*) data;
     double a = d.a, b = d.b;
     if (grad) {
         grad[0] = 3 * a * (a*x[0] + b) * (a*x[0] + b);
         grad[1] = -1.0;
     }
     return ((a*x[0] + b) * (a*x[0] + b) * (a*x[0] + b) - x[1]);
}

void main() {
     import core.stdc.stdio: printf;
     import core.stdc.math: HUGE_VAL;

     double[2] lb = [-HUGE_VAL, 0]; /* lower bounds */
     nlopt_opt opt;

     opt = nlopt_create(NLOPT_LD_MMA, 2); /* algorithm and 
dimensionality */
     nlopt_set_lower_bounds(opt, lb.ptr);
     nlopt_set_min_objective(opt, &myfunc, null);

     my_constraint_data[2] data = [{2,0}, {-1,1}];

     nlopt_add_inequality_constraint(opt, &myconstraint, &data[0], 
1e-8);
     nlopt_add_inequality_constraint(opt, &myconstraint, &data[1], 
1e-8);

     nlopt_set_xtol_rel(opt, 1e-4);

     double[2] x = [1.234, 5.678];  /* `*`some` `initial` 
`guess`*` */
     double minf = void; /* `*`the` `minimum` `objective` `value,` 
`upon` `return`*` */
     if (nlopt_optimize(opt, x.ptr, &minf) < 0) {
         printf("nlopt failed!\n");
     }
     else {
         printf("found minimum at f(%g,%g) = %0.10g\n", x[0], 
x[1], minf);
     }

     nlopt_destroy(opt);
}

```

[1] 
https://github.com/stevengj/nlopt/blob/master/doc/docs/NLopt_Tutorial.md
May 11 2023
prev sibling parent bachmeier <no spam.net> writes:
On Friday, 5 May 2023 at 22:56:20 UTC, bachmeier wrote:


 The `import qnorm` line tells DMD to pull in the code from 
 qnorm.c in that same directory. I don't need to add qnorm.c in 
 the compilation command, which is

 ```
 dmd test.d -P-I. -P-I../gnuwin32/fixed/h -P-I../include 
 -L/usr/lib/libR.so
 ```


This statement is wrong. If it's included in the compilation 
command like this

```
dmd test.d qnorm.c -P-I. -P-I../gnuwin32/fixed/h -P-I../include 
-L/usr/lib/libR.so
```

the file qnorm.c is compiled and Rf_qnorm5 comes from there. If 
it's excluded

```
dmd test.d -P-I. -P-I../gnuwin32/fixed/h -P-I../include 
-L/usr/lib/libR.so
```

it's pulled from libR.so.
May 05 2023
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/28/2023 7:25 AM, bachmeier wrote:

 Looks like you've made a lot of progress the last few months. I was going to 
 file some bug reports to help you out. I tested DMD (latest commit on Github) 
 with a couple of C programs that were not close to compiling in late December. 
 Unfortunately there were no issues today. There was no difference when
compiling 
 and running using dmd or gcc.



Excellent!
Apr 28 2023
prev sibling next sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Thursday, 27 April 2023 at 20:16:32 UTC, Walter Bright wrote:

 Try using ImportC on various popular C .h files on your 
 platform.


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

Or just try to import "Windows.h", which should be in "um" 
subdirectory your Windows SDK's "Include" directory.
Apr 29 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/29/2023 3:09 AM, Max Samukha wrote:

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


Thanks for the help!
Apr 29 2023
parent Max Samukha <maxsamukha gmail.com> writes:
On Saturday, 29 April 2023 at 20:20:28 UTC, Walter Bright wrote:

 On 4/29/2023 3:09 AM, Max Samukha wrote:

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


 Thanks for the help!


One more: https://issues.dlang.org/show_bug.cgi?id=23870
Apr 30 2023
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 27 April 2023 at 20:16:32 UTC, Walter Bright wrote:


 Thanks! Every .h file we can make work makes ImportC that much 
 more useful. It's a high leverage activity for time invested.


I filed one earlier today:

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

Seems to have an easy fix. I added

#define __builtin_isnan isnan

to the .c file and it compiled.
Apr 29 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/29/2023 2:00 PM, bachmeier wrote:

 On Thursday, 27 April 2023 at 20:16:32 UTC, Walter Bright wrote:
 

 Thanks! Every .h file we can make work makes ImportC that much more useful. 
 It's a high leverage activity for time invested.


 
 I filed one earlier today:
 
 https://issues.dlang.org/show_bug.cgi?id=23867
 
 Seems to have an easy fix. I added
 
 #define __builtin_isnan isnan
 
 to the .c file and it compiled.


Do a PR to add this to importc.h and take the credit for the fix!
Apr 29 2023
parent reply bachmeier <no spam.net> writes:
On Saturday, 29 April 2023 at 21:41:51 UTC, Walter Bright wrote:

 On 4/29/2023 2:00 PM, bachmeier wrote:

 On Thursday, 27 April 2023 at 20:16:32 UTC, Walter Bright 
 wrote:
 

 Thanks! Every .h file we can make work makes ImportC that 
 much more useful. It's a high leverage activity for time 
 invested.


 
 I filed one earlier today:
 
 https://issues.dlang.org/show_bug.cgi?id=23867
 
 Seems to have an easy fix. I added
 
 #define __builtin_isnan isnan
 
 to the .c file and it compiled.


 Do a PR to add this to importc.h and take the credit for the 
 fix!


I'll give it a try. There's a similar trivial fix for the other 
issue I created.
Apr 29 2023
parent bachmeier <no spam.net> writes:
On Saturday, 29 April 2023 at 21:50:03 UTC, bachmeier wrote:

 On Saturday, 29 April 2023 at 21:41:51 UTC, Walter Bright wrote:

 On 4/29/2023 2:00 PM, bachmeier wrote:

 On Thursday, 27 April 2023 at 20:16:32 UTC, Walter Bright 
 wrote:
 

 Thanks! Every .h file we can make work makes ImportC that 
 much more useful. It's a high leverage activity for time 
 invested.


 
 I filed one earlier today:
 
 https://issues.dlang.org/show_bug.cgi?id=23867
 
 Seems to have an easy fix. I added
 
 #define __builtin_isnan isnan
 
 to the .c file and it compiled.


 Do a PR to add this to importc.h and take the credit for the 
 fix!


 I'll give it a try. There's a similar trivial fix for the other 
 issue I created.


Now I can add "compiler developer" to my resume.

https://github.com/dlang/dmd/pull/15147
Apr 29 2023
prev sibling next sibling parent Max Samukha <maxsamukha gmail.com> writes:
On Thursday, 27 April 2023 at 20:16:32 UTC, Walter Bright wrote:

 It turns out that every platform we support has "Standard" .h


https://issues.dlang.org/show_bug.cgi?id=23879
May 02 2023
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 27 April 2023 at 20:16:32 UTC, Walter Bright wrote:

 It turns out that every platform we support has "Standard" .h 
 files that won't compile with Standard C11. They all rely on 
 multiple extensions, each platform with a different set of 
 reliances (usually unnecessary).

 [snip]


Does ImportC work with WSL? I started up my dual boot of linux 
for the first time in a few years and everything was pretty out 
of date and I don't feel like dealing with it.
May 03 2023
parent reply bachmeier <no spam.net> writes:
On Wednesday, 3 May 2023 at 14:54:10 UTC, jmh530 wrote:

 On Thursday, 27 April 2023 at 20:16:32 UTC, Walter Bright wrote:

 It turns out that every platform we support has "Standard" .h 
 files that won't compile with Standard C11. They all rely on 
 multiple extensions, each platform with a different set of 
 reliances (usually unnecessary).

 [snip]


 Does ImportC work with WSL? I started up my dual boot of linux 
 for the first time in a few years and everything was pretty out 
 of date and I don't feel like dealing with it.


I use a Windows laptop from time to time. Haven't encountered any 
problems using WSL. You probably want to build the latest DMD 
from Github if you want to use ImportC.
May 03 2023
parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 3 May 2023 at 15:10:12 UTC, bachmeier wrote:

 On Wednesday, 3 May 2023 at 14:54:10 UTC, jmh530 wrote:

 On Thursday, 27 April 2023 at 20:16:32 UTC, Walter Bright 
 wrote:

 It turns out that every platform we support has "Standard" .h 
 files that won't compile with Standard C11. They all rely on 
 multiple extensions, each platform with a different set of 
 reliances (usually unnecessary).

 [snip]


 Does ImportC work with WSL? I started up my dual boot of linux 
 for the first time in a few years and everything was pretty 
 out of date and I don't feel like dealing with it.


 I use a Windows laptop from time to time. Haven't encountered 
 any problems using WSL. You probably want to build the latest 
 DMD from Github if you want to use ImportC.


Thanks.
May 03 2023
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On Thursday, 27 April 2023 at 20:16:32 UTC, Walter Bright wrote:

 Thanks! Every .h file we can make work makes ImportC that much 
 more useful. It's a high leverage activity for time invested.


Just filed this one that seems to be a regression from the last 
major release: https://issues.dlang.org/show_bug.cgi?id=23913
May 12 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
Thank you, I'll check it out.
May 12 2023
prev sibling parent a11e99z <black80 bk.ru> writes:
On Thursday, 27 April 2023 at 20:16:32 UTC, Walter Bright wrote:

 Try using ImportC on various popular C .h files on your 
 platform. For the ones that fail to compile, please find the 
 offending few lines of code and post them to bugzilla.


ImportC for libuv (x64_windows):
[https://forum.dlang.org/post/nztzlruptckjcplukpxl forum.dlang.org](https://forum.dlang.org/post/nztzlruptckjcplukpxl forum.dlang.org)
May 25 2023