Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Init ldc at 1.3.0, fix bootstrap dmd build, fix dtools test, run dmd-testsuite in checkPhase and fix Foundation framework #28635

Merged
merged 5 commits into from Sep 15, 2017

Conversation

ThomasMader
Copy link
Contributor

@ThomasMader ThomasMader commented Aug 28, 2017

Motivation for this change

I wanted to add the D programming language compiler ldc to nixpkgs.

Things done
  • DMD wasn't building on Linux anymore because the default compiler was switched from gcc5 to gcc6 and the bootstrap compiler doesn't seem to build with that version anymore.
    Fixed by using gcc5 for the bootstrap compiler only on Linux.

  • dtools rdmd test wasn't successful anymore because std.stdiobase isn't available anymore.

  • Added ldc package which fulfills it's testsuite (except cppa.d test of dmd-testsuite because it doesn't work for now)

  • Added dmd-testsuite run to dmd compiler as an additional test. (except cppa.d test because it doesn't work for now)

  • Fixed Foundation framework in apple_sdk. (see also fatal error: 'CoreFoundation/CFAttributedString.h' file not found #13778)
    The dmd testsuite uses this on OSX and it complained about not finding the header file:

... runnable/testmodule.d ()
runnable/extra-files/objc_objc_msgSend.m:1:9: fatal error: 'Foundation/Foundation.h' file not found
#import <Foundation/Foundation.h>
^~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
failed to execute 'clang -m64 -c runnable/extra-files/objc_objc_msgSend.m -o test_results/runnable/objc_objc_msgSend.m.o'
make[1]: *** [Makefile:152: test_results/runnable/objc_objc_msgSend.d.out] Error 1


  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • Linux
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@mention-bot
Copy link

@ThomasMader, thanks for your PR! By analyzing the history of the files in this pull request, we identified @nckx, @pikajude and @vlstill to be potential reviewers.

description = "The LLVM-based D compiler";
homepage = https://github.com/ldc-developers/ldc;
# from https://github.com/ldc-developers/ldc/blob/master/LICENSE
license = with licenses; [ bsd3 boost mit ncsa gpl2Plus ];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want to maintain it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about that.
Not sure what it means in reality though.
In fact I plan to keep all D related development stuff going as time permits.
I don't like it either that there is no maintainer for all D related stuff.
So i guess the difference is just a formality right? (I know about adding my name into maintainers list, I already did it in a PR a few year back which was never merged fully)

Copy link
Member

@Mic92 Mic92 Aug 28, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might be consulted in pull requests as a reviewer and you get emails from hydra, when the build of this compiler fails. How much time you want to spent is up to you. Being a package maintainer in nixpkgs has usually less implications compared to other linux/package distributions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds nice.
I added myself to the maintainers. Thanks.

cmake \
-DCMAKE_INSTALL_PREFIX=$out \
-DINCLUDE_INSTALL_DIR=$out/include/dlang/ldc \
..
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be necessary. Try to add cmake to buildInputs and set cmakeFlagsArray=("-DINCLUDE_INSTALL_DIR=$out/include/dlang/ldc") in preConfigure instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, done.


installPhase = ''
make install
'';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is the default of installPhase

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, done.

@ThomasMader
Copy link
Contributor Author

@Mic92 Do you happen to know what to do about the timeout on Travis?

The checkPhases happen to be very long now but they are producing regular output to stdout and I haven't witnessed a stall for multiple minutes on my machines.

@ThomasMader ThomasMader changed the title Init ldc at 1.3.0, fix bootstrap dmd build, run dmd-testsuite in checkPhase and fix Foundation framework Init ldc at 1.3.0, fix bootstrap dmd build, fix dtools test, run dmd-testsuite in checkPhase and fix Foundation framework Aug 28, 2017
@@ -46,7 +46,7 @@ with frameworks; with libs; {
ExceptionHandling = [];
FWAUserLib = [];
ForceFeedback = [ CF IOKit ];
Foundation = [ CF libobjc Security ApplicationServices SystemConfiguration ];
Foundation = [ cf-private CF libobjc Security ApplicationServices SystemConfiguration ];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's been a while since I looked at this but I'm a little concerned at what this does. This may end up working, but I think it's a little hacky. "ApplicationServices" will already add cf-private as a framework and I think the reason this works is because clang will just use the first "CF" it finds (in this case cf-private). I think we need to look at just including cf-private in CF as that distinction doesn't really exist outside Nixpkgs.

/cc @copumpkin

Copy link
Member

@copumpkin copumpkin Aug 28, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you're going to add it, please comment why it was needed. In a slightly more ideal world, cf-private wouldn't really exist at all, so I want to keep track of what requires it and why (even just as a link to the other ticket).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a comment to link to this PR because in here it explains why it is needed for ldc and a further reference to the other bug exists anyway.

@Mic92
Copy link
Member

Mic92 commented Aug 28, 2017

@ThomasMader yes, for big builds, travis is sometimes useless. There were actually plans to let hydra take over. Just ignore the build failure, we usually build manually before merging in this case.

…ecause CoreFoundation/CFAttributedString.h could not be found.

The problem appeared when building ldc on Mac OSX. See also 13778.
@ThomasMader
Copy link
Contributor Author

Ok from my side everything is finished and ready to be merged.

This bug also fixes the build of dmd referenced in #28643 and a further build problem with dtools not yet detected because dmd fails to build on master.

@trishume
Copy link
Contributor

I'm looking forward to this fix. Might also be worth looking into using the dmd-cxx branch that they are maintaining a little bit. This thread mentions it in the context of the new GCC build issue: http://forum.dlang.org/post/mailman.4916.1500319853.31550.dlang-internal@puremagic.com

@ThomasMader
Copy link
Contributor Author

Might also be worth looking into using the dmd-cxx branch that they are maintaining a little bit. This thread mentions it in the context of the new GCC build issue: http://forum.dlang.org/post/mailman.4916.1500319853.31550.dlang-internal@puremagic.com

Thanks, thats very valuable information.
I will try to fix it this way in a future PR. I also always wondered how they used 2.068.2 as the bootstrap version because it contains idgen in D. That information is in that thread too.

@Mic92 Mic92 merged commit 4198692 into NixOS:master Sep 15, 2017
@Mic92
Copy link
Member

Mic92 commented Sep 15, 2017

Thanks! I will also remove broken = true from dmd.

@ThomasMader
Copy link
Contributor Author

ThomasMader commented Sep 15, 2017

@Mic92 Thank you for merging.

I saw that Hydra still isn't able to build the bootstrap dmd compiler. (https://hydra.nixos.org/build/61091111)
I looked into it and the problem is the getpwnam_r C lib call (https://linux.die.net/man/3/getpwnam_r) in https://github.com/dlang/phobos/blob/v2.067.1/std/path.d#L2991 .
This function returns the proper home directory for a given user but on Hydra this directory for user root is not "/root" but "/build" which is not standard.
The problem is that "/root" is expected in the unittest of dmd/phobos and so the build fails.

The problem can be reproduced on other machines if the home directory for user root is changed to something different. e.g.: usermod -m -d /build root

Now the question is if it is possible to fix the home directory for the root user on Hydra. I think this would be the cleaner configuration as "/root" is the default on Linux systems.

@Mic92
Copy link
Member

Mic92 commented Sep 15, 2017

I think /etc/passwd in the nix sandbox just contains the build user and not the root user. Can just skip this test? If the root cause is known, this is ok. We also do it for some tests in go.

@ThomasMader
Copy link
Contributor Author

ThomasMader commented Sep 15, 2017

I highly doubt that because getpwnam_r would fail for a non existing username and the assert output would be "~root". (See https://github.com/dlang/phobos/blob/v2.067.1/std/path.d#L3086)
The build on Darwin works too but that has a different configuration for sure.
(https://hydra.nixos.org/build/61092059)

I also have nix.useSandbox = true in my /etc/nixos/configuration.nix and that should enable the sandboxing if I build with nix-build no?

@Mic92
Copy link
Member

Mic92 commented Sep 15, 2017

Hydra runs nixUnstable, which does provide additional sandboxing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants