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

perlPackages: undefine LD per default in builder #29128

Closed
wants to merge 1 commit into from

Conversation

timor
Copy link
Member

@timor timor commented Sep 8, 2017

Since CC Wrapper defines LD as 'ld', it interferes with MakeMaker
which wants to set LD to $CC, but cannot. This PR ensures that the Value
which is defined by the perl package itself takes precedence.

Motivation for this change

Several perl packages only build when setting LD to $CC or unsetting LD to let the perl build mechanism take care of figuring out the linker.

Things done

I tested a couple of perl packages locally, which wouldn't build before. It is unclear to me, however, how to test this completely, since it seems that perl packages are not very stable and regularly built by Hydra. It takes a long time to build all of them, and some fail due to other reasons as far as I can tell.

  • 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.

Since CC Wrapper defines LD as 'ld', it interferes with MakeMaker
which wants to set LD to CC, but cannot.  This ensures that the Value
which is defined by the perl package itself takes precedence.
Copy link
Member

@Ericson2314 Ericson2314 left a comment

Choose a reason for hiding this comment

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

Putting it in the generic builder is fine, but please continue doing export LD=$CC. Alternatively, maybe MakeMaker could have a setup hook which does this?

@timor
Copy link
Member Author

timor commented Sep 8, 2017

@Ericson2314 Does setting it to $CC ensure that it resolves to $CXX if the compilation is done for XSpp?

@Ericson2314
Copy link
Member

@timor It won't. Does that matter?

@Ericson2314
Copy link
Member

I suppose I am comming around to this a bit, seeing that there isn't really a notion of cross-build a perl module.

@timor
Copy link
Member Author

timor commented Sep 8, 2017

In a recent example (Slic3r, was not a perlPackage package though) there was the same symptom, and the fix was making sure that LD was eventually resolved to g++. As far as I can tell, the perl build process takes care that the correct linker command is chosen. Thus I think that unsetting LD may be more general.

@Ericson2314
Copy link
Member

@timor In general, build systems shouldn't allowed to do their environment checks to decide these things---while not necessarily non-deterministic, it is overly dynamic and complex. Especially with cross compilation, they don't always do a very good job of choosing the right too either.

cc vs ld is a matter of completely different syntax, namely -Wl,arg vs plain arg. But cc vs c++ is a more subtle matter of default linker inputs. an -xc or -xc++ flag should be enough to have cc act as c++ or vise-versa.

Anyways, so if cross-built perl derivations will never make sense, then I relent and unset LD is fine, but if not, it sounds like no one knows what LD=$CC will cause here?

@timor
Copy link
Member Author

timor commented Sep 9, 2017

Yeah, no idea which one is the correct one. Feel free to pick one, I'll change the pull request accordingly.

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

2 participants