www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - How to run lit tests on Mac OSX without gcc?

reply Thomas Mader <thomas.mader gmail.com> writes:
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/linkin
/Output/flag1cache" "-vv" "-run"
"/private/tmp/nix-build-ldc-1.3.0.drv-1/tests/linking/ir2obj_caching_flags1.d"

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.
Aug 26 2017
next sibling parent reply Johan Engelen <j j.nl> writes:
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/linkin
/Output/flag1cache" "-vv" "-run"
"/private/tmp/nix-build-ldc-1.3.0.drv-1/tests/linking/ir2obj_caching_flags1.d"

 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.
This is strange; is it the only lit test that fails? Or do all lit tests fail that need to link? I am developing (almost exclusively) on Mac and the lit tests definitely work. LDC uses "gcc" for linking, also on Mac, where it forwards to clang (with minor tweak). This is not particular to the lit tests. Does "gcc" not work on your commandline? -Johan
Aug 26 2017
parent reply Thomas Mader <thomas.mader gmail.com> writes:
On Saturday, 26 August 2017 at 14:55:23 UTC, Johan Engelen wrote:
 This is strange; is it the only lit test that fails? Or do all 
 lit tests fail that need to link?

 I am developing (almost exclusively) on Mac and the lit tests 
 definitely work. LDC uses "gcc" for linking, also on Mac, where 
 it forwards to clang (with minor tweak). This is not particular 
 to the lit tests. Does "gcc" not work on your commandline?
No there is no gcc available because I am trying to make a Nix (https://nixos.org/nix/) package which is a pure and deterministic approach to building packages. Because of that only the dependencies which are defined explicitly are available for the build. In my case I haven't added gcc as an dependency because I thought it would work without it. But if I understand you correctly than it isn't possible to link without gcc because it's needed for the redirect and there is no possibility for an override?
Aug 26 2017
parent reply Jon Degenhardt <jond noreply.com> writes:
On Saturday, 26 August 2017 at 15:54:30 UTC, Thomas Mader wrote:
 On Saturday, 26 August 2017 at 14:55:23 UTC, Johan Engelen 
 wrote:
 This is strange; is it the only lit test that fails? Or do all 
 lit tests fail that need to link?

 I am developing (almost exclusively) on Mac and the lit tests 
 definitely work. LDC uses "gcc" for linking, also on Mac, 
 where it forwards to clang (with minor tweak). This is not 
 particular to the lit tests. Does "gcc" not work on your 
 commandline?
No there is no gcc available because I am trying to make a Nix (https://nixos.org/nix/) package which is a pure and deterministic approach to building packages. Because of that only the dependencies which are defined explicitly are available for the build. In my case I haven't added gcc as an dependency because I thought it would work without it. But if I understand you correctly than it isn't possible to link without gcc because it's needed for the redirect and there is no possibility for an override?
OS X with xcode installed normally has a 'gcc' command in usr/bin that points to clang. I have both clang and real gcc (via macports) installed on my system. The version is /usr/bin is clang. This allows build systems to refer to 'gcc'. Not sure what part of the xcode setup is involved, perhaps command line tools setup? On my system: $ /usr/bin/gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 8.1.0 (clang-802.0.42) Target: x86_64-apple-darwin16.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Aug 26 2017
parent reply Thomas Mader <thomas.mader gmail.com> writes:
On Saturday, 26 August 2017 at 16:12:56 UTC, Jon Degenhardt wrote:
 OS X with xcode installed normally has a 'gcc' command in 
 usr/bin that points to clang. I have both clang and real gcc 
 (via macports) installed on my system. The version is /usr/bin 
 is clang. This allows build systems to refer to 'gcc'. Not sure 
 what part of the xcode setup is involved, perhaps command line 
 tools setup? On my system:

 $ /usr/bin/gcc --version
 Configured with: 
 --prefix=/Applications/Xcode.app/Contents/Developer/usr 
 --with-gxx-include-dir=/usr/include/c++/4.2.1
 Apple LLVM version 8.1.0 (clang-802.0.42)
 Target: x86_64-apple-darwin16.7.0
 Thread model: posix
 InstalledDir: 
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
On my system /usr/bin/gcc differs from /usr/bin/clang. But I just added the gcc dependency as it's needed on all platforms anyway. Will see if everything is working then. Thanks a lot to both of you.
Aug 26 2017
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
Hi Thomas,

On 26 Aug 2017, at 17:39, Thomas Mader via digitalmars-d-ldc wrote:
 On my system /usr/bin/gcc differs from /usr/bin/clang.

 But I just added the gcc dependency as it's needed on all platforms 
 anyway.
 Will see if everything is working then.

 Thanks a lot to both of you.
You shouldn't need the "real" gcc on OS X – in fact I'd discourage using it for a package distributed to other people, as it might come with unexpected compatibility issues. I've (re)installed quite a few macOS machines with developer tools over the last couple of years, and every time, both /usr/bin/cc and /usr/bin/gcc ended up pointing to a Clang wrapper. You might want to track down what's going wrong. Best, David
Aug 26 2017
parent reply Thomas Mader <thomas.mader gmail.com> writes:
On Saturday, 26 August 2017 at 16:49:02 UTC, David Nadlinger 
wrote:
 You shouldn't need the "real" gcc on OS X – in fact I'd 
 discourage using it for a package distributed to other people, 
 as it might come with unexpected compatibility issues.

 I've (re)installed quite a few macOS machines with developer 
 tools over the last couple of years, and every time, both 
 /usr/bin/cc and /usr/bin/gcc ended up pointing to a Clang 
 wrapper. You might want to track down what's going wrong.
You are right and I probably wouldn't be able to get that merged into upstream this way too. The thing with Nix is that every dependency need to be fixed at build time and can't change anymore. I was able to find the code where the path to gcc is searched for linking and I just replaced "gcc" with "clang" in driver/tool.cpp. Since the CC environment flag is properly set by nix with the full path to clang, it can be found and no gcc is needed at all. I wonder though why there is a special case for FreeBSD in there with clang but not for Mac OSX.
Aug 26 2017
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-08-27 00:31, Thomas Mader wrote:

 You are right and I probably wouldn't be able to get that merged into 
 upstream this way too.
 
 The thing with Nix is that every dependency need to be fixed at build 
 time and can't change anymore.
 I was able to find the code where the path to gcc is searched for 
 linking and I just replaced "gcc" with "clang" in driver/tool.cpp.
 Since the CC environment flag is properly set by nix with the full path 
 to clang, it can be found and no gcc is needed at all.
Can you create a symlink called "gcc" pointing to "clang" and package that? To avoid modifying the source code. -- /Jacob Carlborg
Aug 27 2017
next sibling parent reply Thomas Mader <thomas.mader gmail.com> writes:
On Monday, 28 August 2017 at 06:19:35 UTC, Jacob Carlborg wrote:
 On 2017-08-27 00:31, Thomas Mader wrote:

 You are right and I probably wouldn't be able to get that 
 merged into upstream this way too.
 
 The thing with Nix is that every dependency need to be fixed 
 at build time and can't change anymore.
 I was able to find the code where the path to gcc is searched 
 for linking and I just replaced "gcc" with "clang" in 
 driver/tool.cpp.
 Since the CC environment flag is properly set by nix with the 
 full path to clang, it can be found and no gcc is needed at 
 all.
Can you create a symlink called "gcc" pointing to "clang" and package that? To avoid modifying the source code.
This seems to be an unnecessary redirection and isn't the way such things are handled in Nix AFAIK. I need to patch sources any way because there are other inpure paths in phobos too. See the package for dmd for example: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/dmd/default.nix#L44-L65 But I see that it's a problem to directly use clang because without wrapping there might go something wrong. But if clang wouldn't be supported directly the FreeBSD condition would be wrong too. So with my current knowledge I would suggest that I open a PR to add a condition for OSX with clang too.
Aug 28 2017
parent David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 28 Aug 2017, at 9:52, Thomas Mader via digitalmars-d-ldc wrote:
 But I see that it's a problem to directly use clang because without 
 wrapping there might go something wrong.
That won't be an issue, Clang is GCC-compatible for all the commonly used flags by design.
 So with my current knowledge I would suggest that I open a PR to add a 
 condition for OSX with clang too.
I'd suggest looking into why CC isn't automatically picked up first. — David
Aug 28 2017
prev sibling next sibling parent Thomas Mader <thomas.mader gmail.com> writes:
On Monday, 28 August 2017 at 06:19:35 UTC, Jacob Carlborg wrote:
 On 2017-08-27 00:31, Thomas Mader wrote:

 You are right and I probably wouldn't be able to get that 
 merged into upstream this way too.
 
 The thing with Nix is that every dependency need to be fixed 
 at build time and can't change anymore.
 I was able to find the code where the path to gcc is searched 
 for linking and I just replaced "gcc" with "clang" in 
 driver/tool.cpp.
 Since the CC environment flag is properly set by nix with the 
 full path to clang, it can be found and no gcc is needed at 
 all.
Can you create a symlink called "gcc" pointing to "clang" and package that? To avoid modifying the source code.
This seems to be an unnecessary redirection and isn't the way such things are handled in Nix AFAIK. I need to patch sources any way because there are other inpure paths in phobos too. See the package for dmd for example: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/dmd/default.nix#L44-L65 But I see that it's a problem to directly use clang because without wrapping there might go something wrong. But if clang wouldn't be supported directly the FreeBSD condition would be wrong too. So with my current knowledge I would suggest that I open a PR to add a condition for OSX with clang too.
Aug 28 2017
prev sibling next sibling parent Thomas Mader <thomas.mader gmail.com> writes:
On Monday, 28 August 2017 at 06:19:35 UTC, Jacob Carlborg wrote:
 On 2017-08-27 00:31, Thomas Mader wrote:

 You are right and I probably wouldn't be able to get that 
 merged into upstream this way too.
 
 The thing with Nix is that every dependency need to be fixed 
 at build time and can't change anymore.
 I was able to find the code where the path to gcc is searched 
 for linking and I just replaced "gcc" with "clang" in 
 driver/tool.cpp.
 Since the CC environment flag is properly set by nix with the 
 full path to clang, it can be found and no gcc is needed at 
 all.
Can you create a symlink called "gcc" pointing to "clang" and package that? To avoid modifying the source code.
This seems to be an unnecessary redirection and isn't the way such things are handled in Nix AFAIK. I need to patch sources any way because there are other inpure paths in phobos too. See the package for dmd for example: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/dmd/default.nix#L44-L65 But I see that it's a problem to directly use clang because without wrapping there might go something wrong. But if clang wouldn't be supported directly the FreeBSD condition would be wrong too. So with my current knowledge I would suggest that I open a PR to add a condition for OSX with clang too.
Aug 28 2017
prev sibling next sibling parent reply Thomas Mader <thomas.mader gmail.com> writes:
On Monday, 28 August 2017 at 06:19:35 UTC, Jacob Carlborg wrote:
 On 2017-08-27 00:31, Thomas Mader wrote:

 You are right and I probably wouldn't be able to get that 
 merged into upstream this way too.
 
 The thing with Nix is that every dependency need to be fixed 
 at build time and can't change anymore.
 I was able to find the code where the path to gcc is searched 
 for linking and I just replaced "gcc" with "clang" in 
 driver/tool.cpp.
 Since the CC environment flag is properly set by nix with the 
 full path to clang, it can be found and no gcc is needed at 
 all.
Can you create a symlink called "gcc" pointing to "clang" and package that? To avoid modifying the source code.
This seems to be an unnecessary redirection and isn't the way such things are handled in Nix AFAIK. I need to patch sources any way because there are other inpure paths in phobos too. See the package for dmd for example: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/dmd/default.nix#L44-L65 But I see that it's a problem to directly use clang because without wrapping there might go something wrong. But if clang wouldn't be supported directly the FreeBSD condition would be wrong too. So with my current knowledge I would suggest that I open a PR to add a condition for OSX with clang too.
Aug 28 2017
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 28 Aug 2017, at 17:50, Thomas Mader via digitalmars-d-ldc wrote:
 This seems to be an unnecessary redirection and isn't the way such 
 things are handled in Nix AFAIK.
 I need to patch sources any way because there are other inpure paths 
 in phobos too.

 See the package for dmd for example: 
 https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/dmd/default.nix#L44-L65

 But I see that it's a problem to directly use clang because without 
 wrapping there might go something wrong.
 But if clang wouldn't be supported directly the FreeBSD condition 
 would be wrong too.
 So with my current knowledge I would suggest that I open a PR to add a 
 condition for OSX with clang too.
Your email client is either running amok, or you are sending the same two messages over and over again. Either way, please make it stop. Thanks! —David
Aug 28 2017
parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 28 August 2017 at 17:27:46 UTC, David Nadlinger wrote:
 On 28 Aug 2017, at 17:50, Thomas Mader via digitalmars-d-ldc 
 wrote:
 This seems to be an unnecessary redirection and isn't the way 
 such things are handled in Nix AFAIK.
 I need to patch sources any way because there are other inpure 
 paths in phobos too.

 See the package for dmd for example: 
 https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/dmd/default.nix#L44-L65

 But I see that it's a problem to directly use clang because 
 without wrapping there might go something wrong.
 But if clang wouldn't be supported directly the FreeBSD 
 condition would be wrong too.
 So with my current knowledge I would suggest that I open a PR 
 to add a condition for OSX with clang too.
Your email client is either running amok, or you are sending the same two messages over and over again. Either way, please make it stop. Thanks! —David
There was a problem where the forum frontend wasn't posting messages, but then posted them all later. Happened to me on a different thread, guessing it's what happened here too.
Aug 28 2017
parent reply Thomas Mader <thomas.mader gmail.com> writes:
On Monday, 28 August 2017 at 19:17:28 UTC, Joakim wrote:
 There was a problem where the forum frontend wasn't posting 
 messages, but then posted them all later.  Happened to me on a 
 different thread, guessing it's what happened here too.
Exactly
Aug 28 2017
parent David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 28 Aug 2017, at 20:40, Thomas Mader via digitalmars-d-ldc wrote:
 On Monday, 28 August 2017 at 19:17:28 UTC, Joakim wrote:
 There was a problem where the forum frontend wasn't posting messages, 
 but then posted them all later.  Happened to me on a different 
 thread, guessing it's what happened here too.
Exactly
No worries – just wanted to make sure you are aware of it, since more copies of your original message were coming in, but no replies to my reply. — David
Aug 28 2017
prev sibling parent Thomas Mader <thomas.mader gmail.com> writes:
On Monday, 28 August 2017 at 06:19:35 UTC, Jacob Carlborg wrote:
 Can you create a symlink called "gcc" pointing to "clang" and 
 package that? To avoid modifying the source code.
This seems to be an unnecessary redirection and isn't the way such things are handled in Nix AFAIK. I need to patch sources any way because there are other inpure paths in phobos too. See the package for dmd for example: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/dmd/default.nix#L44-L65 But I see that it's a problem to directly use clang because without wrapping there might go something wrong. But if clang wouldn't be supported directly the FreeBSD condition would be wrong too. So with my current knowledge I would suggest that I open a PR to add a condition for OSX with clang too.
Aug 28 2017
prev sibling parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 26 Aug 2017, at 23:31, Thomas Mader via digitalmars-d-ldc wrote:
 The thing with Nix is that every dependency need to be fixed at build 
 time and can't change anymore.
 I was able to find the code where the path to gcc is searched for 
 linking and I just replaced "gcc" with "clang" in driver/tool.cpp.
 Since the CC environment flag is properly set by nix with the full 
 path to clang, it can be found and no gcc is needed at all.
I'm still not sure I understand. Are you saying that Nix purposely doesn't allow the system Xcode installation to be found (which makes sense for a reproducible build system), but doesn't provide a `gcc` symlink in its Clang/Xcode/… package? Also, if the CC environment variable is set to the path of an executable, LDC should automatically use it already. What the default program is should be inconsequential then.
 I wonder though why there is a special case for FreeBSD in there with 
 clang but not for Mac OSX.
Presumably FreeBSD does not provide a `gcc` symlink by default, unlike Xcode/macOS. You'd have to ask Kai (https://github.com/ldc-developers/ldc/pull/1117) for details, though. — David
Aug 28 2017
parent reply Thomas Mader <thomas.mader gmail.com> writes:
On Monday, 28 August 2017 at 08:55:22 UTC, David Nadlinger wrote:
 I'm still not sure I understand. Are you saying that Nix 
 purposely doesn't allow the system Xcode installation to be 
 found (which makes sense for a reproducible build system), but 
 doesn't provide a `gcc` symlink in its Clang/Xcode/… package?
Exactly, all packages are under /nix/store/ and each package has a different directory in which all files are contained. The name of the directory starts with a hash which describes the container uniquely and changes each time something in the build description of the package changes or some dependency package changes. The dependencies are nothing else then the full paths to the container directories in /nix/store Everything should be pure (work in progress) and so the OS clang package isn't used. Nix needs to provide that on it's own. I opened an issue for it: https://github.com/NixOS/nixpkgs/issues/28647 You are right that if the default system provides the symlink, Nix should too. But as you said in your later post, ldc works with clang and clang is the default on Darwin, so it seems nicer to just support it that way.
 Also, if the CC environment variable is set to the path of an 
 executable, LDC should automatically use it already. What the 
 default program is should be inconsequential then.
If I understood the ldc code correctly (driver/tool.cpp), only gcc is searched for in the environment but not clang. clang is used on FreeBSD only.
Aug 28 2017
next sibling parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 28 Aug 2017, at 21:01, Thomas Mader via digitalmars-d-ldc wrote:
 If I understood the ldc code correctly (driver/tool.cpp), only gcc is 
 searched for in the environment but not clang. clang is used on 
 FreeBSD only.
https://github.com/ldc-developers/ldc/blob/37390e5764494da77a925f8586b2e1187ef08076/driver/tool.cpp#L47-L49 Where would the restriction to `gcc` come in? —David
Aug 28 2017
parent reply Thomas Mader <thomas.mader gmail.com> writes:
On Monday, 28 August 2017 at 20:09:39 UTC, David Nadlinger wrote:
 Where would the restriction to `gcc` come in? —David
https://github.com/ldc-developers/ldc/blob/37390e5764494da77a925f8586b2e1187ef08076/driver/tool.cpp#L26 and https://github.com/ldc-developers/ldc/blob/37390e5764494da77a925f8586b2e1187ef08076/driver/tool.cpp#L70 I patched both to get it working for now.
Aug 28 2017
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 28 Aug 2017, at 21:13, Thomas Mader via digitalmars-d-ldc wrote:
 https://github.com/ldc-developers/ldc/blob/37390e5764494da77a925f8586b2e1187ef08076/driver/tool.cpp#L26
This is just the name of the command line flag.
 https://github.com/ldc-developers/ldc/blob/37390e5764494da77a925f8586b2e1187ef08076/driver/tool.cpp#L70

 I patched both to get it working for now.
None of these should be relevant if CC is set, as per the snippet I linked. Note that the default is only used after the env check. The fact that this doesn't seem to work indicates a bug in that logic, or in the way the environment is set up. What is CC actually set to? — David
Aug 28 2017
parent reply Thomas Mader <thomas.mader gmail.com> writes:
On Monday, 28 August 2017 at 20:18:30 UTC, David Nadlinger wrote:
 None of these should be relevant if CC is set, as per the 
 snippet I linked. Note that the default is only used after the 
 env check. The fact that this doesn't seem to work indicates a 
 bug in that logic, or in the way the environment is set up. 
 What is CC actually set to?
CC is set to the full path to clang (/nix/store/<hash>-<packagename>-<version>/bin) So it seems that findProgramByName returns empty because it's already a full path. (https://github.com/ldc-developers/ldc/blob/master/driver/tool.cpp#L48) A check is missing to see if there already is a full path given in CC.
Aug 28 2017
next sibling parent reply kinke <noone nowhere.com> writes:
On Monday, 28 August 2017 at 20:48:40 UTC, Thomas Mader wrote:
 On Monday, 28 August 2017 at 20:18:30 UTC, David Nadlinger 
 wrote:
 None of these should be relevant if CC is set, as per the 
 snippet I linked. Note that the default is only used after the 
 env check. The fact that this doesn't seem to work indicates a 
 bug in that logic, or in the way the environment is set up. 
 What is CC actually set to?
CC is set to the full path to clang (/nix/store/<hash>-<packagename>-<version>/bin)
It needs to be set to the binary, not its containing directory. Try adding /clang.
Aug 28 2017
parent Thomas Mader <thomas.mader gmail.com> writes:
On Monday, 28 August 2017 at 20:54:36 UTC, kinke wrote:
 On Monday, 28 August 2017 at 20:48:40 UTC, Thomas Mader wrote:
 On Monday, 28 August 2017 at 20:18:30 UTC, David Nadlinger 
 wrote:
 None of these should be relevant if CC is set, as per the 
 snippet I linked. Note that the default is only used after 
 the env check. The fact that this doesn't seem to work 
 indicates a bug in that logic, or in the way the environment 
 is set up. What is CC actually set to?
CC is set to the full path to clang (/nix/store/<hash>-<packagename>-<version>/bin)
It needs to be set to the binary, not its containing directory. Try adding /clang.
Yes I forgot to add the /clang. It's late. ;-)
Aug 28 2017
prev sibling parent reply Thomas Mader <thomas.mader gmail.com> writes:
On Monday, 28 August 2017 at 20:48:40 UTC, Thomas Mader wrote:
 On Monday, 28 August 2017 at 20:18:30 UTC, David Nadlinger 
 wrote:
 None of these should be relevant if CC is set, as per the 
 snippet I linked. Note that the default is only used after the 
 env check. The fact that this doesn't seem to work indicates a 
 bug in that logic, or in the way the environment is set up. 
 What is CC actually set to?
CC is set to the full path to clang (/nix/store/<hash>-<packagename>-<version>/bin)
No that might not be the case, normally it's just "clang" I guess. Need to check that tomorrow.
Aug 28 2017
parent reply Thomas Mader <thomas.mader gmail.com> writes:
On Monday, 28 August 2017 at 20:55:48 UTC, Thomas Mader wrote:
 No that might not be the case, normally it's just "clang" I 
 guess. Need to check that tomorrow.
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. I guess with this setup "findProgramByName" should find the full path to clang. Next I will try to build the package without my "gcc" -> "clang" substitution. Maybe it didn't work on some older version of nixpkgs because there was an error. If it is still not working I need to debug into it more deeply.
Aug 28 2017
parent reply Thomas Mader <thomas.mader gmail.com> writes:
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; }
Aug 30 2017
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
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
Aug 30 2017
parent reply Thomas Mader <thomas.mader gmail.com> writes:
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. :-)
Aug 30 2017
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
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
Aug 31 2017
parent reply Johan Engelen <j j.nl> writes:
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
Aug 31 2017
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
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
Aug 31 2017
parent Johan Engelen <j j.nl> writes:
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
Sep 02 2017
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-08-28 22:01, Thomas Mader wrote:

 But as you said in your later post, ldc works with clang and clang is 
 the default on Darwin, so it seems nicer to just support it that way.
I think it make sense to look for "clang" these days. It's been the system compiler for many years now. -- /Jacob Carlborg
Aug 28 2017
prev sibling next sibling parent Johan Engelen <j j.nl> writes:
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:
By the way, a quick way to just run the lit-tests is to go to the tests subdirectory of your build dir, and run runlit.py (note the dot "." at the end): ``` ../build/tests> ./runlit.py -v . ``` -Johan
Aug 26 2017
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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/linkin
/Output/flag1cache" "-vv" "-run"
"/private/tmp/nix-build-ldc-1.3.0.drv-1/tests/linking/ir2obj_caching_flags1.d"

 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>
Sep 03 2017
next sibling parent Thomas Mader <thomas.mader gmail.com> writes:
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.
Sep 03 2017
prev sibling parent David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
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
Sep 03 2017