Re: Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)

["Burton, Ross" <ross.burton@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

On 27 September 2017 at 13:57, Bryan Evenson <bevenson@melinkcorp.com>
wrote:

>
> Feel free to compress and email it directly to me, but simply grepping for
> EINVAL (invalid argument error) might be enough.
>
>
>
> I did a search on EINVAL and I got a bunch of entries of that look like
> this:
>
>
>
>   linkat(AT_FDCWD, “<source_full_path>”, AT_FDCWD, “<dest_full_path>”, 0)
> = -1 EINVAL (Invalid argument)
>
>
>
> I checked a few entries by doing a stat on the source and destination.  In
> each case, the source file exists at the specified path, was owned by the
> user account with which I’m doing the build, and had access rights of
> 0644.  Also in each case, the destination file did not exist but the
> destination directory did exist, the destination directory was owned by the
> user account with which I’m doing the build, and the destination directory
> had access rights of 0755.  From reading the man page for linkat, linkat
> should only return EINVAL if the flags argument is invalid, and 0 should be
> a valid value for flags.
>
>
>
> I think there may be something missing from WSL’s implementation of
> linkat.  I am doing OPKG packages, so I’m guessing there is something
> different about the resulting function calls in the libc-package class as
> opposed to the package_ipk class.  I think I may enable the other package
> types to see if it is as successfully with RPMs and DEB packages.  I’m also
> going to see if there is an easier way to reproduce the problem to report
> the issue to Microsoft.
>

Good digging.  At least you can replicate it on demand, and have a strace
showing it.  This bit of packaging happens before the rpm/opkg/deb specific
code, so changing the packaging format won't help.

Ross

[-- Attachment #2: Type: text/html, Size: 3215 bytes --]