digitalmars.D.ldc - How to run lit tests on Mac OSX without gcc?
- Thomas Mader (14/14) Aug 26 2017 I am successfully building ldc 1.3.0 on Mac and running the
- Johan Engelen (8/22) Aug 26 2017 This is strange; is it the only lit test that fails? Or do all
- Thomas Mader (11/17) Aug 26 2017 No there is no gcc available because I am trying to make a Nix
- Jon Degenhardt (16/36) Aug 26 2017 OS X with xcode installed normally has a 'gcc' command in usr/bin
- Thomas Mader (6/21) Aug 26 2017 On my system /usr/bin/gcc differs from /usr/bin/clang.
- David Nadlinger via digitalmars-d-ldc (11/16) Aug 26 2017 You shouldn't need the "real" gcc on OS X – in fact I'd discourage
- Thomas Mader (12/19) Aug 26 2017 You are right and I probably wouldn't be able to get that merged
- Jacob Carlborg (5/14) Aug 27 2017 Can you create a symlink called "gcc" pointing to "clang" and package
- Thomas Mader (13/27) Aug 28 2017 This seems to be an unnecessary redirection and isn't the way
- David Nadlinger via digitalmars-d-ldc (5/9) Aug 28 2017 That won't be an issue, Clang is GCC-compatible for all the commonly
- Thomas Mader (13/27) Aug 28 2017 This seems to be an unnecessary redirection and isn't the way
- Thomas Mader (13/27) Aug 28 2017 This seems to be an unnecessary redirection and isn't the way
- Thomas Mader (13/27) Aug 28 2017 This seems to be an unnecessary redirection and isn't the way
- David Nadlinger via digitalmars-d-ldc (4/16) Aug 28 2017 Your email client is either running amok, or you are sending the same
- Joakim (4/23) Aug 28 2017 There was a problem where the forum frontend wasn't posting
- Thomas Mader (2/5) Aug 28 2017 Exactly
- David Nadlinger via digitalmars-d-ldc (4/9) Aug 28 2017 No worries – just wanted to make sure you are aware of it, since more
- Thomas Mader (13/15) Aug 28 2017 This seems to be an unnecessary redirection and isn't the way
- David Nadlinger via digitalmars-d-ldc (12/20) Aug 28 2017 I'm still not sure I understand. Are you saying that Nix purposely
- Thomas Mader (21/28) Aug 28 2017 Exactly, all packages are under /nix/store/ and each package has
- David Nadlinger via digitalmars-d-ldc (3/6) Aug 28 2017 https://github.com/ldc-developers/ldc/blob/37390e5764494da77a925f8586b2e...
- Thomas Mader (5/6) Aug 28 2017 https://github.com/ldc-developers/ldc/blob/37390e5764494da77a925f8586b2e...
- David Nadlinger via digitalmars-d-ldc (7/10) Aug 28 2017 None of these should be relevant if CC is set, as per the snippet I
- Thomas Mader (8/13) Aug 28 2017 CC is set to the full path to clang
- kinke (3/12) Aug 28 2017 It needs to be set to the binary, not its containing directory.
- Thomas Mader (2/15) Aug 28 2017 Yes I forgot to add the /clang. It's late. ;-)
- Thomas Mader (3/12) Aug 28 2017 No that might not be the case, normally it's just "clang" I
- Thomas Mader (11/13) Aug 28 2017 I just checked. CC is set to "clang" correctly and clang is
- Thomas Mader (16/20) Aug 30 2017 The thing is that "getenv(envVar)" returns "(null)" even though
- David Nadlinger via digitalmars-d-ldc (5/8) Aug 30 2017 Oh, so it looks like perhaps lit just doesn't forward `CC` by default at...
- Thomas Mader (4/14) Aug 30 2017 "config.environmen['CC'] = 'clang'" added to
- David Nadlinger via digitalmars-d-ldc (4/6) Aug 31 2017 @Johan: Does this ring a bell – is there something special to be done
- Johan Engelen (10/16) Aug 31 2017 We don't want to pass through all env variables, as it is going
- David Nadlinger via digitalmars-d-ldc (6/13) Aug 31 2017 I'm not sure I'd agree with it disrupting testing any more than other
- Johan Engelen (3/11) Sep 02 2017 https://github.com/ldc-developers/ldc/pull/2306
- Jacob Carlborg (5/7) Aug 28 2017 I think it make sense to look for "clang" these days. It's been the
- Johan Engelen (8/11) Aug 26 2017 By the way, a quick way to just run the lit-tests is to go to the
- Nicholas Wilson (4/18) Sep 03 2017 ldc has a -gcc flag to override the gcc used for linking, it is
- Thomas Mader (6/12) Sep 03 2017 Yes I found that one already somewhere in the forums but it
- David Nadlinger via digitalmars-d-ldc (8/11) Sep 03 2017 The flag does indeed exist. However, it is not intended for regular
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
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
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
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: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/binThis 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
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/binOn 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
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
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
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
On Monday, 28 August 2017 at 06:19:35 UTC, Jacob Carlborg wrote:On 2017-08-27 00:31, Thomas Mader 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.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.
Aug 28 2017
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
On Monday, 28 August 2017 at 06:19:35 UTC, Jacob Carlborg wrote:On 2017-08-27 00:31, Thomas Mader 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.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.
Aug 28 2017
On Monday, 28 August 2017 at 06:19:35 UTC, Jacob Carlborg wrote:On 2017-08-27 00:31, Thomas Mader 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.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.
Aug 28 2017
On Monday, 28 August 2017 at 06:19:35 UTC, Jacob Carlborg wrote:On 2017-08-27 00:31, Thomas Mader 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.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.
Aug 28 2017
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
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: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.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
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
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: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. — DavidThere 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
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
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
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
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
On Monday, 28 August 2017 at 20:09:39 UTC, David Nadlinger wrote:Where would the restriction to `gcc` come in? —Davidhttps://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
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#L26This 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
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
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:It needs to be set to the binary, not its containing directory. Try adding /clang.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)
Aug 28 2017
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:Yes I forgot to add the /clang. It's late. ;-)On Monday, 28 August 2017 at 20:18:30 UTC, David Nadlinger wrote:It needs to be set to the binary, not its containing directory. Try adding /clang.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)
Aug 28 2017
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:No that might not be the case, normally it's just "clang" I guess. Need to check that tomorrow.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)
Aug 28 2017
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
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
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
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:"config.environmen['CC'] = 'clang'" added to "tests/lit.site.cfg.in" gets it going. :-)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
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
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: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"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?
Aug 31 2017
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
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:https://github.com/ldc-developers/ldc/pull/2306We 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.
Sep 02 2017
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
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
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
On Sunday, 3 September 2017 at 10:46:23 UTC, Nicholas Wilson wrote: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.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
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