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

nixos/cc-wrapper: Fix bug if dynamicLinker not found #31209

Merged
merged 3 commits into from Nov 6, 2017

Conversation

bnikolic
Copy link
Contributor

@bnikolic bnikolic commented Nov 3, 2017

If a dynamic linker for target is not found the generated script fails
due to unbound variable error (in turn due to "set -u"). Correct by specifying
default value with dynamicLinker:- and not generating ldflagsBefore if
no linker is found.

This problem was found when cross compiling to mingw32 targets

Motivation for this change

Cross-compiling for mingw32 targets was currently broken with "variable unbound" errors. This change allows the compilation to proceed further.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • 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.

If a dynamic linker for target is not found the generated script fails
due to unbound variable error (due to "set -u"). Correct by specifying
default value with dynamicLinker:- and not generating ldflagsBefore if
no linker is found.

This problem was found when cross compiling to mingw32 targets
@vcunat
Copy link
Member

vcunat commented Nov 3, 2017

@Ericson2314 knows cross-compiling best, I guess.

@orivej
Copy link
Contributor

orivej commented Nov 3, 2017

This does not look right, the variable is always initialized a few lines above. And why would dynamicLinker=($dynamicLinker) not fail too?

@bnikolic
Copy link
Contributor Author

bnikolic commented Nov 3, 2017 via email

@@ -286,7 +286,7 @@ stdenv.mkDerivation {
*) echo "Multiple dynamic linkers found for platform '${targetPlatform.config}'." >&2;;
esac

if [ -n "$dynamicLinker" ]; then
if [ -n "''${dynamicLinker:-}" ]; then
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 correct, good catch.

@@ -296,7 +296,9 @@ stdenv.mkDerivation {
echo ${libc_lib}/lib/32/ld-linux.so.2 > $out/nix-support/dynamic-linker-m32
fi

local ldflagsBefore=(-dynamic-linker "$dynamicLinker")
if [ -n "''${dynamicLinker:-}" ]; then
Copy link
Member

Choose a reason for hiding this comment

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

This second conditional is unneeded, no?

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 already part of the first, unless I messed up the string interpolation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're right, I missed the indentation. Pushing a revised patch now

@globin
Copy link
Member

globin commented Nov 6, 2017

@nixborg build

@vcunat vcunat merged commit 3a63fc1 into NixOS:staging Nov 6, 2017
@nixborg
Copy link

nixborg commented Nov 6, 2017

Jobset created at https://hydra.mayflower.de/jobset/nixos/pr-31209

@vcunat
Copy link
Member

vcunat commented Nov 6, 2017

@globin: it's included in staging now, so you may want to save resources for other stuff.

@Ericson2314
Copy link
Member

Thanks @bnikolic! Btw I'm happy to pitch on various MinGW-related things, especially as they bitrotted further a bit under my watch. @domenkozar and @DavidEGrayson may also be interested.

@bnikolic
Copy link
Contributor Author

bnikolic commented Nov 6, 2017 via email

@DavidEGrayson
Copy link
Contributor

DavidEGrayson commented Nov 6, 2017

@bnikolic I'm not sure if this is helpful for your sys-includes problem, but I use two patches for mingw-w64 GCC to make the search paths correct:

https://github.com/DavidEGrayson/nixcrpkgs/blob/6501664/mingw-w64/gcc/cppdefault.patch
https://github.com/DavidEGrayson/nixcrpkgs/blob/6501664/mingw-w64/gcc/mingw-search-paths.patch

The default search path for my toolchain is:

 /nix/store/hvi2parp3nrcvic4ls6yppdq43nbjpgz-gcc-6.3.0-i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.3.0/include
 /nix/store/hvi2parp3nrcvic4ls6yppdq43nbjpgz-gcc-6.3.0-i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.3.0/include-fixed
 /nix/store/7n257w326q1i0xdshgm2l35ywmik50y9-mingw-w64-2017-08-03-i686-w64-mingw32/include
 /nix/store/hvi2parp3nrcvic4ls6yppdq43nbjpgz-gcc-6.3.0-i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.3.0/../../../../i686-w64-mingw32/include

You might also want to look at the Arch Linux recipe for mingw-w64-gcc:

https://www.archlinux.org/packages/community/x86_64/mingw-w64-gcc/

The default header search path is defined in gcc/cppdefault.c and is controlled by several variables from target-specific headers. (Sometimes the target-specific headers tell cppdefault.c exactly what to do, bypassing all the logic in it. But I think that's not the case for MinGW.)

@bnikolic
Copy link
Contributor Author

@DavidEGrayson I've resolved the mingw-w64 problems in #33167 -- cross-compilation to win64 target seems to work with this.

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

Successfully merging this pull request may close these issues.

None yet

8 participants