zyc.fftw.native 3.3.11

zyc.fftw.native

An unofficial repackaging of FFTW 3.3.11. This package is not published, maintained, or endorsed by the FFTW project or MIT. The binaries are built with MSVC from the unmodified official fftw-3.3.11.tar.gz release sources.

FFTW was developed by Matteo Frigo and Steven G. Johnson. Copyright holders include Matteo Frigo and the Massachusetts Institute of Technology (MIT); see the copyright notices in the source files. MIT refers to the institution here, not the MIT software license.

Supported configuration

• Windows x64; intended consumers are Visual Studio 2022 native C++ vcxproj projects using v143 and packages.config.
• Double precision: fftw3.dll and fftw3.lib.
• Single precision: fftw3f.dll and fftw3f.lib.
• SSE2 baseline. AVX, AVX2, long double, quad precision, OpenMP, and FFTW thread libraries are disabled.
• The DLLs use RelWithDebInfo and the default dynamic release CRT (/MD). The same DLLs serve both Debug and Release consumers. The package does not change the consumer's RuntimeLibrary setting.
• The targets file adds the include directory, both import libraries, and the FFTW_DLL definition, then copies both DLLs to the consumer's $(OutDir). Win32 and ARM64 are unsupported. This package does not provide a .NET wrapper.

The current local binaries were built and tested with VS 2026 / v145. Validation with VS 2022 / v143 is still pending. The build script defaults to VS 2022 / v143; see VALIDATION.md in the packaging workspace for the recorded checks.

The target machine needs the x64 Microsoft Visual C++ v14 Redistributable, at least as recent as the MSVC tools used to build the DLLs. Dependencies include vcruntime140.dll and the UCRT (ucrtbase.dll, which may appear in the import table through api-ms-win-crt-*.dll API-set names). Install the redistributable rather than manually copying a single runtime DLL. The package does not bundle the VC++ runtime. See the official Microsoft downloads. The build script records the exact direct dependencies in fftw3-dependents.txt and fftw3f-dependents.txt.

Usage requirements

1. Pair fftw_malloc with fftw_free. For single precision, pair fftwf_malloc with fftwf_free. Do not mix these allocations with free or delete.
2. For wisdom, use fftw_export_wisdom_to_filename and fftw_import_wisdom_from_filename, or the corresponding fftwf_ functions. Do not pass a consumer-owned FILE* into the DLL. Debug consumers normally use /MDd and ucrtbased.dll, while these DLLs use ucrtbase.dll. Avoid the same issue with other FFTW APIs that accept FILE*. To print a plan, use fftw_sprint_plan and release the returned string with fftw_free.
3. Define FFTW_DLL so the original fftw3.h declares dllimport correctly, particularly for exported data symbols such as fftw_version. The package targets file supplies this definition; no header modification is needed.

Source, license, and symbols

FFTW is licensed under GPL-2.0-or-later. The original license text is included as COPYING. Using a DLL or accepting a license prompt does not remove any applicable GPL obligations. Users who need terms other than the GPL can purchase a commercial license from MIT's Technology Licensing Office. See the FFTW license information for contact details. This package does not grant a commercial license.

• Official source: fftw-3.3.11.tar.gz.
• Official project: FFTW.
• The original tarball is included at source/fftw-3.3.11.tar.gz.
• SHA-256: 5630c24cdeb33b131612f7eb4b1a9934234754f9f388ff8617458d0be6f239a1. This hash identifies the build input downloaded from the official HTTPS URL; it is not an upstream signature.
• The complete build script is build.ps1 in the packaging workspace and is included verbatim as source/build.ps1.txt. The installation integration is build/native/zyc.fftw.native.targets. These packaging files are also provided under GPL-2.0-or-later. The publisher should retain the script, nuspec, and README for every released version in a public packaging repository. The .ps1.txt extension preserves the script without triggering NuGet's NU5110/NU5111 installation-script warnings. Do not rename the build script to install.ps1 or init.ps1 to silence those warnings.

GPLv2 section 3 includes scripts that control compilation and installation in the complete source code. This package includes the corresponding original tarball, build script, and targets file together. The tarball adds about 4 MB, but reduces the risk of broken upstream links, mismatched sources, and separate source distribution locations. Linking to the upstream tarball and publishing the build script separately makes the package smaller, but a link alone should not be assumed to satisfy every source distribution requirement. Consider equivalent access from the same place, continued availability, and an exact match to the binaries. A written source offer carries continuing obligations; a generic statement that source is available on request is not a substitute. These are distribution risk points, not legal advice.

The matching native linker PDBs for both DLLs are included directly in build/native/bin/x64. The nuget.org .snupkg symbol service does not accept native Windows PDBs. This package does not create a .snupkg or use nuget pack -Symbols. PDBs are not copied to the application output directory. To load them, add the package's symbol directory in Visual Studio under Tools > Options > Debugging > Symbols. Source debugging also requires extracting the included sources and locating the corresponding files in VS; Source Link is not configured. PDBs may contain build-machine paths, so use a stable build directory without personal information for public releases.

SIMD and upstream test findings

The options in the original 3.3.11 CMakeLists.txt are ENABLE_SSE2, ENABLE_AVX, and ENABLE_AVX2; ENABLE_SSE also exists. Both precision builds use ENABLE_SSE2=ON, ENABLE_AVX=OFF, and ENABLE_AVX2=OFF.

Upstream implements runtime dispatch. simd-support/avx.c and avx2.c check CPU features and OSXSAVE through CPUID, then use XGETBV to check operating-system support for saving XMM/YMM state. The MSVC path in amd64-cpuid.h uses __cpuidex and _xgetbv. CMake applies AVX/AVX2 options to the corresponding codelet files, and dft/conf.c and rdft/conf.c register those codelets only after the CPU checks pass. Do not add /arch:AVX2 to global CFLAGS or the CL environment variable: that can introduce advanced instructions into ordinary code before runtime feature checks execute.

This package uses SSE2 to keep the compatibility and validation scope small. Upstream AVX2 codelets use FMA, but avx2.c does not independently test the FMA feature bit; CMake also has a separate FMA flag detection path. Before enabling AVX/AVX2 in a future package, inspect the actual compiler options and validate on non-AVX, AVX-only, and AVX2/FMA CPUs or controlled virtual machines. Passing on a single AVX2 machine does not validate fallback behavior. This package does not require an AVX or AVX2 CPU.

BUILD_TESTS=ON builds bench.exe. However, the original CMake registers its 32x64 and ib256 CTest cases only when Threads_FOUND is true, and those cases use the bench -s speed mode. Since this package disables threads, a CTest run with no tests is not a correctness check. The build script directly invokes upstream bench -y for both precisions, covering a two-dimensional transform, an in-place backward transform, a prime length, and real forward/backward transforms. These are representative checks, not the complete upstream Perl check.pl test matrix.

The 3.3.11 tarball has an upstream version-field issue: its CMake file still sets FFTW_VERSION to 3.3.10. As a result, fftw_version and fftwf_version may report 3.3.10. The sources are left unmodified. The pinned tarball SHA-256 and release identity determine the source version used for this package.

Build and pack, in order

Install Visual Studio 2022 with Desktop development with C++, v143, a Windows SDK, and CMake. Windows tar and either Windows PowerShell 5.1 or PowerShell 7 are also required. Open Developer PowerShell for VS 2022 and enable x64 tools:

Enter-VsDevShell -VsInstallPath $env:VSINSTALLDIR -DevCmdArguments '-arch=x64 -host_arch=x64' -SkipAutomaticLocation
Set-Location C:\d\zyc.fftw
Get-Command cmake, tar, dumpbin

Do not inject additional options such as /MT or /arch:AVX2 through CL, CL, CFLAGS, or CXXFLAGS. The DLL build uses the default /MD. Use the official release tarball, not the GitHub development tree.

# Download, verify, extract, build both precisions, test, install, and stage.
.\build.ps1

# Use the pinned NuGet CLI; dotnet pack is not needed.
New-Item -ItemType Directory -Force .\tools | Out-Null
Invoke-WebRequest 'https://dist.nuget.org/win-x86-commandline/v6.14.0/nuget.exe' -OutFile .\tools\nuget.exe
New-Item -ItemType Directory -Force .\artifacts\nupkg | Out-Null
.\tools\nuget.exe pack .\zyc.fftw.native.nuspec -BasePath .\artifacts\package -OutputDirectory .\artifacts\nupkg -NonInteractive -ForceEnglishOutput
if ($LASTEXITCODE -ne 0) { throw 'nuget pack failed' }

To rebuild the DLLs from an extracted .nupkg, run Copy-Item .\source\build.ps1.txt .\build.ps1 in the extraction root, then run .\build.ps1. To recreate the NuGet package, use the original nuspec from the packaging repository.

The nuspec author is zyc. Its projectUrl currently points to the upstream project. Once the packaging repository is public, use its actual URL and add matching repository metadata. Do not invent a repository URL. The complete build commands are in build.ps1. With CMake 4.x, the script supplies -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to accommodate upstream's older minimum version declaration without modifying source. CMake 3.x does not receive this variable.

The script refuses to reuse an existing output directory. For another build, use -OutputDirectory .\artifacts-r1 and adjust the pack paths accordingly. The Generator and Toolset parameters allow explicit checks in other build environments. Use their defaults for the intended v143 build. Keep package analysis enabled; do not hide pack issues with -NoPackageAnalysis or NoWarn.

To repack the existing local v145 build after editing documentation, use:

Copy-Item .\README.md .\artifacts-msvc145-check\package\README.md
New-Item -ItemType Directory -Force .\dist | Out-Null
.\tools\nuget.exe pack .\zyc.fftw.native.nuspec -BasePath .\artifacts-msvc145-check\package -OutputDirectory .\dist -NonInteractive -ForceEnglishOutput
if ($LASTEXITCODE -ne 0) { throw 'nuget pack failed' }

Package layout (the original nuspec stays in the packaging repository; NuGet writes its own manifest into the package):

README.md
COPYING
source/build.ps1.txt
source/fftw-3.3.11.tar.gz
build/native/zyc.fftw.native.targets
build/native/include/fftw3.h
build/native/lib/x64/fftw3.lib
build/native/lib/x64/fftw3f.lib
build/native/bin/x64/fftw3.dll
build/native/bin/x64/fftw3f.dll
build/native/bin/x64/fftw3.pdb
build/native/bin/x64/fftw3f.pdb

Validate locally in a new vcxproj

Create a folder package source. This configuration applies to the packaging workspace, without changing the global source configuration:

New-Item -ItemType Directory -Force .\artifacts\feed | Out-Null
Copy-Item .\artifacts\nupkg\zyc.fftw.native.3.3.11.nupkg .\artifacts\feed\
@"
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="fftw-local" value="artifacts\feed" />
  </packageSources>
</configuration>
"@ | Set-Content -Encoding UTF8 .\NuGet.Config

When testing the existing local v145 package instead, copy .\dist\zyc.fftw.native.3.3.11.nupkg to the same feed directory.

In VS 2022, create a new C++ Console App named FftwSmoke, with the solution under C:\d\zyc.fftw\smoke-vs. Select v143 and x64. Open Tools > NuGet Package Manager > Package Manager Console and run the following command there:

Install-Package zyc.fftw.native -Version 3.3.11.0 -Source C:\d\zyc.fftw\artifacts\feed -ProjectName FftwSmoke

Accept the GPL license prompt. Check that packages.config is created with targetFramework="native", and that the vcxproj's ExtensionTargets imports build\native\zyc.fftw.native.targets. The external nuget.exe install command only downloads and extracts packages; it does not add these vcxproj imports. Replace the default project cpp file with the contents of smoke/main.cpp from the packaging workspace. Let the package provide the include paths, libraries, FFTW_DLL, and DLL copying so that the integration is exercised by the test.

Disable precompiled headers for all configurations. Use /MDd for Debug and /MD for Release. Rebuild and run Debug|x64 and Release|x64 in VS. Both should exit with code 0 and print PASS: double + float. The program also accesses exported data symbols to verify the FFTW_DLL definition. With the default VS solution layout, the equivalent Developer PowerShell commands are:

msbuild .\smoke-vs\FftwSmoke\FftwSmoke.sln /t:Rebuild /p:Configuration=Debug /p:Platform=x64 /m
if ($LASTEXITCODE -ne 0) { throw 'Debug build failed' }
& .\smoke-vs\FftwSmoke\x64\Debug\FftwSmoke.exe
if ($LASTEXITCODE -ne 0) { throw 'Debug smoke failed' }

msbuild .\smoke-vs\FftwSmoke\FftwSmoke.sln /t:Rebuild /p:Configuration=Release /p:Platform=x64 /m
if ($LASTEXITCODE -ne 0) { throw 'Release build failed' }
& .\smoke-vs\FftwSmoke\x64\Release\FftwSmoke.exe
if ($LASTEXITCODE -ne 0) { throw 'Release smoke failed' }

Adjust the paths if you chose Place solution and project in the same directory. Verify that both output directories contain fftw3.dll and fftw3f.dll from this package. In Configuration Manager, switch the project to Win32, creating the configuration if necessary. The solution may label this platform as x86. Rebuild and expect this error:

zyc.fftw.native only ships x64 binaries. Select the x64 platform (current: Win32).

You can also build the project directly; a nonzero exit code is expected:

msbuild .\smoke-vs\FftwSmoke\FftwSmoke\FftwSmoke.vcxproj /t:Build /p:Configuration=Debug /p:Platform=Win32
if ($LASTEXITCODE -eq 0) { throw 'Win32 unexpectedly succeeded' }

Check that the failure comes from the package targets. A missing platform configuration or toolset is not a passing result. When changing a local package without changing its version, uninstall it and remove that package's directory from the test solution before reinstalling, or increase the packaging revision to avoid stale caches. Published nuget.org versions cannot be replaced this way.

Publish to nuget.org

Before publishing, check the NuGet package page and your signed-in account to confirm that the ID is available and that your account can publish it. An empty search result does not establish ownership. The personal prefix in zyc.fftw.native and the package description identify it as unofficial. Confirm the author, repository URL, script revision, sources, test results, and pack output before uploading.

Use packaging revisions 3.3.11.0, 3.3.11.1, and so on. NuGet normalizes a zero fourth component away, so 3.3.11.0 produces zyc.fftw.native.3.3.11.nupkg. The versions 3.3.11 and 3.3.11.0 identify the same package version. An existing ID and normalized version cannot be replaced. Publishers can normally unlist a package, not delete it and reuse its version number.

Create a nuget.org Push API key scoped to this package ID. Set NUGET_API_KEY securely in the current session; do not store the key in the repository. Run the following only after local validation is complete:

if (!$env:NUGET_API_KEY) { throw 'Set NUGET_API_KEY in this session first.' }
.\tools\nuget.exe push .\artifacts\nupkg\zyc.fftw.native.3.3.11.nupkg -Source https://api.nuget.org/v3/index.json -ApiKey $env:NUGET_API_KEY -NonInteractive
if ($LASTEXITCODE -ne 0) { throw 'nuget push failed' }

Omit -SkipDuplicate so that version conflicts remain visible. After uploading, check nuget.org validation and install the package from nuget.org in a separate new project. To pack a later revision:

.\tools\nuget.exe pack .\zyc.fftw.native.nuspec -Version 3.3.11.1 -BasePath .\artifacts\package -OutputDirectory .\artifacts\nupkg -NonInteractive -ForceEnglishOutput

requireLicenseAcceptance=true draws attention to the GPL terms during installation. It does not change the license or replace the obligations of the publisher or consumer.