Docs: Run windows build in a clean path #10889

brianmcmichael commented at 2:10 AM on July 21, 2017: contributor

Fixes the error described in #10856

In Windows Subsystem for Linux the entire windows path is now part of the $PATH variable and it interferes with the make command.

bmcmichael@DESKTOP-I6V4RLU:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/ProgramData/Oracle/Java/javapath_target_209286125:
/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0:
/mnt/c/Program Files (x86)/Skype/Phone:/mnt/c/Program Files/Microsoft SQL Server/130/Tools/Binn:
/mnt/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit:/mnt/c/Program Files/Git/cmd:/mnt/c/Program Files/Microsoft DNX/Dnvm:
/mnt/c/Program Files/Microsoft SQL Server/120/Tools/Binn:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:
/mnt/c/Users/brian/AppData/Local/Microsoft/WindowsApps:/mnt/c/Program Files (x86)/Microsoft VS Code/bin:/home/bmcmichael/.fzf/bin

bmcmichael@DESKTOP-I6V4RLU:~$ echo $(getconf PATH)
/bin:/usr/bin

Adding PATH=$(getconf PATH) to the make command runs the process in a clean environment (ex. PATH=/bin:/usr/bin) and allows the build to proceed.

I haven't tested whether the Windows 32-bit build is affected by this so I haven't updated that command.

Docs: Run windows build in a clean path 0b1f407f2a

fanquake added the label Docs and Output on Jul 21, 2017

theuni commented at 4:36 AM on July 21, 2017: member

Thanks!

laanwj commented at 1:30 PM on July 21, 2017: member

Just looking from the description seems an alternative take on #10884.

MattyAB commented at 4:36 PM on July 24, 2017: none

Hmm, can't get this to work... Am I doing something wrong?

https://pastebin.com/2JWMgUBA

brianmcmichael commented at 4:41 PM on July 24, 2017: contributor

Did you install the dependencies first? https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.md#cross-compilation

sudo apt-get install build-essential libtool autotools-dev automake pkg-config bsdmainutils curl

MattyAB commented at 6:42 PM on July 24, 2017: none

Yep, I've done that: https://pastebin.com/JLgPnPMw

onomatopellan commented at 6:50 PM on July 24, 2017: none

@MattyAB I noticed you are compiling on /mnt/d/Documents/bitcoin/depends/. For WSL is better compiling on a LxFS folder (/home/user/) since those folders really have linux-like behavior,

brianmcmichael commented at 6:51 PM on July 24, 2017: contributor

You are running an old version of the tools. Run the following commands:

sudo apt-get update
sudo apt-get upgrade

After that, type automake --version

You want to see the following:

bmcmichael@DESKTOP-8AJB375:~/workbench$ automake --version
automake (GNU automake) 1.14.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey <tromey@redhat.com>
       and Alexandre Duret-Lutz <adl@gnu.org>.

brianmcmichael commented at 7:04 PM on July 24, 2017: contributor

Actually, my bad, it looks like you're using 1.15, which isn't a default in WSL's trusty version, so you're off the reservation. You must have some custom ppa?

You could try typing ln -s automake-1.15 automake-1.14 to fool the compiler.

onomatopellan commented at 7:09 PM on July 24, 2017: none

@brianmcmichael On latest Windows 10 (Creators Update) WSL by default installs Xenial. If Trusty is really needed then it's better to use something like https://github.com/RoliSoft/WSL-Distribution-Switcher in order to switch to the desired linux distribution.

brianmcmichael commented at 7:17 PM on July 24, 2017: contributor

@onomatopellan Thanks, apparently my CU update left the WSL alone and I'm still on trusty. I'll try to get it updated and see if I can build on xenial.

MattyAB commented at 7:17 PM on July 24, 2017: none

@brianmcmichael I wrestled with it to try get it to install automake 1.14, it just wasn't playing. I tried the ln command you suggested, it just gave the same error :(

MattyAB commented at 7:29 PM on July 24, 2017: none

Also did:

//sudo apt-get autoremove automake //sudo apt-get install automake=1.14

but got:

E: Version ‘1.14’ for ‘automake’ was not found

brianmcmichael commented at 7:31 PM on July 24, 2017: contributor

@MattyAB I'm updating to Xenial now. I think I have an idea of what's going wrong, but I want to confirm first. Give me a few hours.

MattyAB commented at 7:40 PM on July 24, 2017: none

@brianmcmichael Awesome, thank you.

brianmcmichael commented at 2:52 AM on July 25, 2017: contributor

Alright, so the existing windows build instructions only really work on trusty, and after the update I'm running into the chain of problems of the type starting at #8511.

It also looks like xenial has some issues that have been going on for a while #8787 (comment)

This will take some untangling to figure out for 16.04. What's interesting is that I didn't run into the automake issue. Were you running with sudo?

MattyAB commented at 9:07 AM on July 25, 2017: none

Yep, tried that:

MattyAB@Horcrux:/mnt/d/Documents/bitcoin/depends$ sudo make HOST=x86_64-w64-mingw32 PATH=$(getconf PATH) [sudo] password for MattyAB: Building native_protobuf... make[1]: Entering directory '/mnt/d/Documents/bitcoin/depends/work/build/x86_64-w64-mingw32/native_protobuf/2.6.1-8ed1124ca21/src' make[2]: Entering directory '/mnt/d/Documents/bitcoin/depends/work/build/x86_64-w64-mingw32/native_protobuf/2.6.1-8ed1124ca21' cd . && /bin/bash /mnt/d/Documents/bitcoin/depends/work/build/x86_64-w64-mingw32/native_protobuf/2.6.1-8ed1124ca21/missing automake-1.14 --foreign /mnt/d/Documents/bitcoin/depends/work/build/x86_64-w64-mingw32/native_protobuf/2.6.1-8ed1124ca21/missing: line 81: automake-1.14: command not found WARNING: 'automake-1.14' is missing on your system. You should only need it if you modified 'Makefile.am' or 'configure.ac' or m4 files included by 'configure.ac'. The 'automake' program is part of the GNU Automake package: <http://www.gnu.org/software/automake> It also requires GNU Autoconf, GNU m4 and Perl in order to run: <http://www.gnu.org/software/autoconf> <http://www.gnu.org/software/m4/> <http://www.perl.org/> Makefile:612: recipe for target 'Makefile.in' failed make[2]: *** [Makefile.in] Error 1 make[2]: Leaving directory '/mnt/d/Documents/bitcoin/depends/work/build/x86_64-w64-mingw32/native_protobuf/2.6.1-8ed1124ca21' Makefile:1222: recipe for target 'Makefile.in' failed make[1]: *** [Makefile.in] Error 1 make[1]: Leaving directory '/mnt/d/Documents/bitcoin/depends/work/build/x86_64-w64-mingw32/native_protobuf/2.6.1-8ed1124ca21/src' funcs.mk:242: recipe for target '/mnt/d/Documents/bitcoin/depends/work/build/x86_64-w64-mingw32/native_protobuf/2.6.1-8ed1124ca21/./.stamp_built' failed make: *** [/mnt/d/Documents/bitcoin/depends/work/build/x86_64-w64-mingw32/native_protobuf/2.6.1-8ed1124ca21/./.stamp_built] Error 2

brianmcmichael commented at 3:01 PM on July 25, 2017: contributor

You shouldn't use sudo on the make commands.

MattyAB commented at 3:18 PM on July 25, 2017: none

It doesn't work with sudo or without.

laanwj commented at 6:14 AM on July 26, 2017: member

Definitely don't add sudo before make! It is only required for apt-get and other system management commands.

brianmcmichael commented at 4:58 AM on July 27, 2017: contributor

At this point the guide should probably be updated to mention that these commands only work on trusty instances in WSL. I hadn't done a release upgrade since I first installed it so I was still running 14.04. Since default WSL instances are being deployed from the Windows Store, even fresh installs of base Windows 10 from old media are getting 16.04 now. I've started working on a solution for WSL xenial builds with mingw but that's probably going to take at least through the weekend to implement and test.

laanwj commented at 11:28 AM on July 27, 2017: member

windows cross-build on xenial has one critical issue still open, #8732 (might be they fixed the compiler for the stack-protector issue since, but I have no reports on that)

MattyAB approved

MattyAB commented at 1:22 PM on August 1, 2017: none

tACK

MattyAB commented at 1:24 PM on August 1, 2017: none

For anyone's interest, I tried it on the pure Linux folder instead of my mount, and it worked. Don't know if this was the problem or not, but it's worth a try.

brianmcmichael commented at 3:21 PM on August 1, 2017: contributor

I can make another PR mentioning that this needs to be done on the Linux folder instead of mnt, and also that currently only trusty is supported pending resolution of #8732

I myself ran into the issue in #8511 on the final make with xenial, but I haven't gotten around to looking at it yet.

fanquake added the label Windows on Aug 19, 2017

in doc/build-windows.md:71 in 0b1f407f2a

  67 | @@ -68,7 +68,7 @@ To build executables for Windows 64-bit, install the following dependencies:
  68 |  Then build using:
  69 |  
  70 |      cd depends
  71 | -    make HOST=x86_64-w64-mingw32
  72 | +    make HOST=x86_64-w64-mingw32 PATH=$(getconf PATH)

laanwj commented at 7:35 AM on August 22, 2017:

Does it also interfere with the other make commands used to build/install bitcoin core itself?

brianmcmichael commented at 1:29 PM on August 22, 2017:

The make command worked successfully on WSL 14.04 using this command. It could potentially break things if people are relying on dependencies outside of /bin:/usr/bin path, but I didn't experience any issues building with only the required dependencies.

laanwj commented at 3:12 PM on August 22, 2017:

Yes, but I mean there's another make later in the document. Does that need this addition as well?

brianmcmichael commented at 3:32 PM on August 22, 2017:

Probably. I wasn't able to test the 32-bit version, so I didn't make the addition here, but I suspect that the command will be plagued by a similar issue.

laanwj assigned laanwj on Aug 22, 2017

laanwj commented at 10:19 PM on September 6, 2017: member

Closing in favor of #11244, which adds PATH override for both 32 and 64 bit.

laanwj closed this on Sep 6, 2017

laanwj unassigned laanwj on Sep 6, 2017

DrahtBot locked this on Sep 8, 2021