Building OpenWrt inside the Windows Subsystem for Linux frequently triggers environment-specific conflicts due to filesystem semantics and permission mappings. The following procedures resolve three recurring build failures.

Resolving Case-Sensitivity Constraints

When executing the feed synchronization routine, the build system halts with a prerequisite validation failure:

Build dependency: OpenWrt can only be built on a case-sensitive filesystem
Prerequisite check failed. Use FORCE=1 to override.
make: *** [/mnt/c/projects/openwrt/include/toplevel.mk:182: staging_dir/host/.prereq-build] Error 1

This error occurs because WSL defaults to mounting NTFS volumes without strict case sensitivity. OpenWrt's Makefiles require precise case handling for package directories and staging paths.

To resolve this, enable the case-sensitive attribute on the workspace directory using a elevated PowerShell session. Substitute C:\dev\openwrt with your actual project path:

PS C:\> fsutil.exe file setCaseSensitiveInfo C:\dev\openwrt enable

After applying the filesystem flag, cached artifacts generated under the previous configuration remain in the tree. Purge the working directory before retrying:

git clean -dfx

Re-executing the feed update command will now successfully pass the case-sensitivity check.

Bypassing Automake Bootstrap Permission Errors

During host toolchain initialization, the build process may terminate with a file creation denial:

./bootstrap: 107: cannot create t/testsuite-part.tmp: Permission denied

Examining the build_dir/host/automake-*/bootstrap script indicates that the failure originates from a temporary test suite generation routine. WSL's file translation layer often restricts rapid permission changes and atomic writes in shared mount points. Since these test components are non-essential for the cross-compilation toolchain, the routine can be safely omitted.

Navigate to the bootstrap script and comment out the test generation block:

# Skip test suite generation to bypass WSL permission mapping conflicts
# $PERL_EXEC ./gen-testsuite-part > t/testsuite-part.tmp
# chmod a-w t/testsuite-part.tmp
# mv -f t/testsuite-part.tmp t/testsuite-part.am

Disabling these lines prevents the permission violation and allows the host package compilation to complete.

Handling Perl Source Patch Failures

The build process frequently fails when applying patches to the Perl host package:

Applying ./patches/001-macos_11_support.patch using plaintext:
patch: **** Can't rename file hints/darwin.sh.oG8fLA9 to hints/darwin.sh : Permission denied
Patch failed!  Please fix ./patches/001-macos_11_support.patch!
make[3]: *** [Makefile:158: build_dir/hostpkg/perl/perl-5.28.1/.prepared] Error 1

The patch utility relies on atomic file renaming, which frequently fails on WSL due to background file indexing or lock contention. A reliible workaround involves pre-applying the patches to the source archive and updating the package manifest.

Extract the original Perl archive from the download cache and verify its checksum:

TARGET_ARCHIVE="perl-5.28.1.tar.xz"
sha256sum dl/${TARGET_ARCHIVE}

Decompress the archive into a working directory and apply all upstream patches directly:

tar -xf dl/${TARGET_ARCHIVE} -C .
mv perl-5.28.1 perl_source_workdir
cd perl_source_workdir
git apply ../../feeds/packages/lang/perl/patches/*.patch

Recompress the modified directory using the original archive format:

cd ..
tar -cf ${TARGET_ARCHIVE} perl_source_workdir
xz -z ${TARGET_ARCHIVE}

Replace the original file in the dl directory and compute the updated checksum:

sha256sum ${TARGET_ARCHIVE}

Modify the package definition to reference the new hash. Update feeds/packages/lang/perl/Makefile:

PKG_SOURCE:=perl-$(PKG_VERSION).tar.xz
PKG_HASH:=<updated_checksum_value>

Remove the original patch directory and clear the Perl build cache to trigger a clean compilation:

rm -rf feeds/packages/lang/perl/patches/
rm -rf build_dir/hostpkg/perl/