On 27 September 2017 at 13:57, Bryan Evenson <beven...@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
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
