Jump to page: 1 24  
Page
Thread overview
August 26
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.
August 26
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.

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

August 26
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

August 26
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?

August 26
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
August 26
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.

August 26
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
August 26
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.

August 28
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
August 28
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.
« First   ‹ Prev
1 2 3 4