On Tuesday, 29 August 2017 at 06:50:15 UTC, Thomas Mader wrote:
> I just checked. CC is set to "clang" correctly and clang is callable.
> Within the PATH variable the path "/nix/store/2dijjcqwnzf0pj1ii524anz55nxm7pjs-clang-wrapper-4.0.1/bin/" is declared and in this directory the clang binary is found.

The thing is that "getenv(envVar)" returns "(null)" even though CC is set to "clang" before "./runlit.py -v ." is called.
Very strange.
I also tested getenv in a little C program and built and run that via Nix but it worked.

      #include <stdio.h>
      #include <stdlib.h>

      int main ()
      {
        char* pCC;
        pCC = getenv ("CC");
        if (pCC!=NULL)
          printf ("The CC is: %s\n",pCC);
        return 0;
      }

On 30 Aug 2017, at 9:43, Thomas Mader via digitalmars-d-ldc wrote:
> The thing is that "getenv(envVar)" returns "(null)" even though CC is set to "clang" before "./runlit.py -v ." is called.
> Very strange.

Oh, so it looks like perhaps lit just doesn't forward `CC` by default at all. Could you try explicitly adding `config.environment['CC'] = …` to lit.site.cfg.in?

 — David

On Wednesday, 30 August 2017 at 14:37:25 UTC, David Nadlinger wrote:
> On 30 Aug 2017, at 9:43, Thomas Mader via digitalmars-d-ldc wrote:
>> The thing is that "getenv(envVar)" returns "(null)" even though CC is set to "clang" before "./runlit.py -v ." is called.
>> Very strange.
>
> Oh, so it looks like perhaps lit just doesn't forward `CC` by default at all. Could you try explicitly adding `config.environment['CC'] = …` to lit.site.cfg.in?
>
>  — David

"config.environmen['CC'] = 'clang'" added to "tests/lit.site.cfg.in" gets it going. :-)

On 30 Aug 2017, at 19:29, Thomas Mader via digitalmars-d-ldc wrote:
> "config.environmen['CC'] = 'clang'" added to "tests/lit.site.cfg.in" gets it going. :-)

@Johan: Does this ring a bell – is there something special to be done for lit to just pass through environment variables?

 — David

On Thursday, 31 August 2017 at 10:59:55 UTC, David Nadlinger wrote:
> On 30 Aug 2017, at 19:29, Thomas Mader via digitalmars-d-ldc wrote:
>> "config.environmen['CC'] = 'clang'" added to "tests/lit.site.cfg.in" gets it going. :-)
>
> @Johan: Does this ring a bell – is there something special to be done for lit to just pass through environment variables?

We don't want to pass through all env variables, as it is going to disrupt testing in strange ways. I take it as a very good thing that Lit does not pass env vars through.

We could pass through specific ones explicitly:
```
  config.environmen['CC'] = os.environ['CC']
```

-Johan

On 31 Aug 2017, at 19:08, Johan Engelen via digitalmars-d-ldc wrote:
> We don't want to pass through all env variables, as it is going to disrupt testing in strange ways. I take it as a very good thing that Lit does not pass env vars through.

I'm not sure I'd agree with it disrupting testing any more than other environmental factors (OS/linker versions, etc.), but fair enough.

> We could pass through specific ones explicitly:
> ```
>   config.environmen['CC'] = os.environ['CC']
> ```

Let's do that, then – it would have been used to compile the standard libraries, etc. before outside of lit anyway.

 — David

On Thursday, 31 August 2017 at 22:58:10 UTC, David Nadlinger wrote:
> On 31 Aug 2017, at 19:08, Johan Engelen via digitalmars-d-ldc wrote:
>
>> We could pass through specific ones explicitly:
>> ```
>>   config.environmen['CC'] = os.environ['CC']
>> ```
>
> Let's do that, then – it would have been used to compile the standard libraries, etc. before outside of lit anyway.

https://github.com/ldc-developers/ldc/pull/2306

On Saturday, 26 August 2017 at 13:45:18 UTC, Thomas Mader wrote:
> I am successfully building ldc 1.3.0 on Mac and running the phobos and druntime tests work too but I get the following error in the lit tests:
>
> 1561: $ "/tmp/nix-build-ldc-1.3.0.drv-1/build/bin/ldc2" "-cache=/private/tmp/nix-build-ldc-1.3.0.drv-1/build/tests/linking/Output/flag1cache" "-vv" "-run" "/private/tmp/nix-build-ldc-1.3.0.drv-1/tests/linking/ir2obj_caching_flags1.d"
> 1561: # command stderr:
> 1561: Error: failed to locate gcc
> 1561:
> 1561: error: command failed with exit status: 1
> 1561: $ "FileCheck" "--check-prefix=COULD_HIT" "/private/tmp/nix-build-ldc-1.3.0.drv-1/tests/linking/ir2obj_caching_flags1.d"
>
> There is no gcc on this system. Is it possible to get the lit tests running without gcc as linker?
> Everything else is built and run with clang.

ldc has a -gcc flag to override the gcc used for linking, it is hidden which is why you didn't find it.

ldc -gcc=/path/to/clang <rest of args>

On Sunday, 3 September 2017 at 10:46:23 UTC, Nicholas Wilson wrote:
>> There is no gcc on this system. Is it possible to get the lit tests running without gcc as linker?
>> Everything else is built and run with clang.
>
> ldc has a -gcc flag to override the gcc used for linking, it is hidden which is why you didn't find it.
>
> ldc -gcc=/path/to/clang <rest of args>

Yes I found that one already somewhere in the forums but it wasn't helping in this case since ldc is called from the lit tests script and the linker needs to be detected via the environment.

On 3 Sep 2017, at 11:46, Nicholas Wilson via digitalmars-d-ldc wrote:
> ldc has a -gcc flag to override the gcc used for linking, it is hidden which is why you didn't find it.
>
> ldc -gcc=/path/to/clang <rest of args>

The flag does indeed exist. However, it is not intended for regular end-users, but rather to help developers when fiddling around with auto-detection/cross-compilation setups, etc. In normal use, the GCC-style linker driver to use should be auto-detected from the CC environment variable. The problem here was just that lit didn't forward it to the test processes.

 — David