WSL “Bash on Windows” as a dev environment

I don’t aim to introduce WSL, or do more than link to installation steps.

I do want to take a quick note of tweaks that have been helpful to me in making WSL more useful as a development environment.

  • If you want to use ping: Find the “Bash on Ubuntu on Windows” shortcut, right-click, more, open file location, right-click, properties, advanced, “Run as administrator”. Presto, ping works. This might not be necessary in future builds.
  • Friendlier colors:
    • Edit .bashrc and add to the bottom:
    • LS_COLORS=$LS_COLORS:'di=1;44:' ; export LS_COLORS
    • Edit .vimrc and add:
    • :set background=dark
    • Optional, not entirely certain about this yet: Right-click the bash icon at the upper left of the bash window, choose Defaults, set “Screen Background” to “Black” (0,0,0) and “Screen Text” to “White” (255,255,255)
  • /mnt/* is not a build environment. If you try to compile something you downloaded in Windows from its /mnt/c or /mnt/* location, copy it over to ~/ or /var/tmp first. /mnt/* is not as “Linux-y” a file system as the Ubuntu environment is, and it might (likely: will) trip up your source builds.
  • Coding in perl 5: Works out of the box from Creators Update on. Until then, edit “/usr/lib/perl/5.18.2/Config.pm” and make sure that you have “dont_use_nlink => 1”, around line 94. It defaults to “dont_use_nlink => undef”.
  • Coding in perl 6: Requires a change to the dyncall library to build successfully for now, until dyncall has been updated. The MoarVM github has two alternate patches that will allow it to build, only one is required.
  • Coding in Swift: Similar issue to perl 6, with a patch available. Your best bet is to clear the executable stack flag in libFoundation.so for now, until Swift 3.1 has been released.
  • Coding with a host of other libraries that refuse to link because of execstack, including OpenSSL: Clearing the executable stack flag on the library will work if the library doesn’t require an executable stack. Upstream changes would be best, however, so things start working “out of the box”. Usually the root cause for a library setting the execstack flag is that assembly files are missing a short section to declare the stack not executable. See the Gentoo wiki entry on this. Here’s the code that would go into a .h file included in every .S file, with NO_EXEC_STACK_DIRECTIVE at the end of relevant .S files. NB, this needs to be .S not .s, as a preprocessor is required in order to parse the include file:
  • #if defined(__GNUC__) && defined(__ELF__) && (defined (_linux__) || defined(__FreeBSD__) || defined(__ANDROID__))
    #define NO_EXEC_STACK_DIRECTIVE .section .note.GNU-stack,"",%progbits
    #elsif defined(__SUNPRO_C) && defined(__linux__)
    #define NO_EXEC_STACK_DIRECTIVE .section ".note.GNU-stack"
    #else
    #define NO_EXEC_STACK_DIRECTIVE
    #endif

    That code is portable using GNU as across architectures, and should work with SUNPro Tools aka Oracle Developer Studio.

    Please also see the WSL github discussion regarding execstack. This really can use attention and will have positive impact beyond WSL when resolved. Requesting an executable stack when it’s not needed is an exploit waiting to happen.