Hello, I ran into this issue when compiling an old large project on Linux with DMD as its C compiler implicitly using ImportC. I was successful: ImportC really came through!

I used CC = dmd in the configuration of the top level Makefile and all was well after some technical rearrangements (e.g. replacing -o by -of= when the compiler is invoked and fixing up old C constructs that DMD didn't like) excepting one part of the build.

That part made a dynamic library, and had to get exactly the right command line arguments to the C compiler for linking so that symbols would be exported and so forth. To do that, it ran a shell script to do the linking containing a branch based upon the output of uname -s. To do that it set shell variables in the environment the script runs in by e.g. in the Makefile the shell command CC="$(CC)" prefixing the command to run the script. Imagine my surprise when I got what follows in the terminal on typing make.

dmd -shared -fPIC -of=libcfunc.so external.o
Error: -o no longer supported, use -of or -od
Error: unrecognized switch '-Xlinker'
Error: unrecognized switch '--export-dynamic'
Error: unrecognized switch '-Xlinker'
Error: unrecognized switch '-Bstatic'
Error: unrecognized switch '-lphobos2'
Error: unrecognized switch '-Xlinker'
Error: unrecognized switch '-Bdynamic'
Error: unrecognized switch '-lpthread'
Error: unrecognized switch '-lm'
Error: unrecognized switch '-lrt'
Error: unrecognized switch '-ldl'
       run `dmd` to print the compiler manual
       run `dmd -man` to open browser on manual
Error: linker exited with status 1

The reason for this is that the shell variable CC is set to CC=dmd when DMD is invoked in the script. It seems that DMD uses its paired C compiler to do the linking and if the shell variable CC is defined, will get the compiler from its value, meaning itself in this case!

The result is what you see: a command line intended for gcc is instead executed with dmd in its place. Naturally dmd knows nothing of the various options used by gcc to invoke the linker at dmd's request and complains accordingly, so at least recursion of this forwarding is prevented.

A test if CC is dmd in the script with unset CC preceding explicit use of dmd in place of $CC works around the problem.

On Thursday, 29 February 2024 at 15:34:43 UTC, Carl Sturtivant wrote:

The linking flags need to be preppended with -L on each: -L-lm -L-lrt -L-lphobos2. It doesn't look like you've done that from the logs

On Thursday, 29 February 2024 at 18:49:00 UTC, Hipreme wrote:

You didn't understand the post! Look at my command line. I didn't use any linking flags. I didn't mention any of those libraries.

On Thursday, 29 February 2024 at 19:16:51 UTC, Walter Bright wrote:

Me too! Very pleased: now the brittle C from the early '80s through the'90s is mutable via D.

I did this on Linux. I used cproto and ctags in a quick and dirty script to replace K&R defs in dozens of source files in one fell swoop. That went surprisingly smoothly.

On Thursday, 29 February 2024 at 20:58:22 UTC, Carl Sturtivant wrote:

DMD_CC=$CC
CC=dmd

I think Rikki is suggesting replacing

const(char)* cc = getenv("CC");

with

const(char)* cc = getenv("DMD_CC");
if (!cc) {
  const(char)* cc = getenv("CC");
}

or something like that. Then you'd set DMD_CC to whatever cc should be used inside DMD.

On Thursday, 29 February 2024 at 21:34:03 UTC, Richard (Rikki) Andrew Cattermole wrote:

What you're proposing would prevent infinite recursion, wouldn't it? Maybe I'm missing something. The source of the problem is grabbing the CC environment variable inside link.d.