Issue 7678: Added -cflag=ccflags switch.

[chadjoan]

This allows arguments to be passed to the C compiler being used to drive linking.

I've also opened issue 7678 for this. (http://d.puremagic.com/issues/show_bug.cgi?id=7678)

I was prompted to make this patch because of issue 5278 remaining unresolved. (http://d.puremagic.com/issues/show_bug.cgi?id=5278)

[WalterBright]

Adding more flags makes me nervous. I keep thinking there must be a better solution.

[alexrp]

Well, -L is already entirely linker-dependent. Does it really matter if we add a switch to pass flags to the C compiler which are compiler-specific? I totally understand your concern, but we already have to special-case anyway, and I very much doubt we can create sensible wrapper options around all supported C compilers on all platforms.

[MartinNowak]

The only reason we're using the compiler driver for linking instead of a linker is to select appropriate libc link parameters. Now there are only few C compiler options that affect the selected libc like -static or -fpie. All of those should be mappable to equivalent D compiler options because the linkage model is the same.
So I think it makes more sense to implement a -fPIE switch or interpreting -fPIC for executables as meaning -fPIE.
The implementation would consist of -fPIC + pass -fPIE to gcc + ?.

If that isn't feasible for now I would opt for detecting a default PIE compiler driver or simply hardcode fno-pie
here.

[andralex]

I'm not an expert in this so I'll assign to @WalterBright.

[MartinNowak]

I'll close this for now. As stated above we can achieve the particular fPIE fix by different means.

[timotheecour]

ping on this. ldc 1.8.0 now has -Xcc (introduced in ldc-developers/ldc#2104)
(also related: https://issues.dlang.org/show_bug.cgi?id=17390)

[wilzbach]

I think you need to find a more support for this (I would support it, but Martin and Walter we against this fine years ago). Maybe a short NG thread is the best option to gather a consensus?

[htfy96]

This is a show stopper for a full dmd-based compilation of libc-free projects without invoking cc manually, since we need to pass -nostdlib directly to cc. (Another is https://issues.dlang.org/show_bug.cgi?id=19106)

[jacob-carlborg]

What abot the CFLAGS environment variable?

[chadjoan]

This stopped being a problem for me years ago, but I still think it is a good idea. I forget if things became better because the PIE/PIC stuff was fixed, or if I just stopped using a hardened system, but there was this period of time where dmd just did not work.

Most abstractions are going to leak from time to time. Unless you have unlimited money and minions, and can thus respond to external change immediately and comprehensively, then there are going to be times when the software ecosystem changes around us and leaves the abstraction broken for new or existing use-cases (obsolescence or regression, respectively). There is no perfect answer to such a problem, but we can at least offer the users of our software ways to bypass our abstractions. This at least allows knowledgeable individuals to craft their own solutions and be able to use your software while you take your time to define use-cases, root-cause problems, make sure solutions are maintainable and orthogonal, and so on.

To me, this seems like one of those places where we should have an abstraction bypass. I wasn't even thinking of -nostdlib when I brought this up, yet here it is, 6 years later.

I don't want to bury Jacob's reasonable question about CFLAGS, so hopefully someone can still answer that. I don't remember and can't test it right now.