Officially FreeTDS for Windows should be compiled using CMake. CMake is able to create project files for different development systems (like Visual C++). Install CMake on your box and point to the source directory to generate wanted files. Refer to CMake documentation on how to do it (I personally use CMake GUI passing source directory and a newly create build directory). Once project files are created you can open them with your environment.
You can download FreeTDS binaries for Windows from AppVeyor (the hosted CI platform used).
There is a .zip file available as artifact of every successful build. The list of builds is at https://ci.appveyor.com/project/FreeTDS/freetds/history. You can find there builds of code in the master branch and (from time to time) builds from the post-1.5 release fixes-only Branch-1_5 branch. Every build matrix element generates its artifact.
The Visual Studio 2026 64 bit and Visual Studio 2022 32 bit builds also provide
a .msi installer. It installs the utilities and libraries and registers the ODBC driver.
Headers and libraries to build applications are optional.
The freetds.conf file in the etc installation directory
is only an example and is not read. If you need a configuration file, you can copy it
to %APPDATA%\.freetds.conf for a single user.
The installer also supports silent installation, for instance
msiexec /i freetds.msi /qn ADDLOCAL=ALL INSTALLDIR="C:\FreeTDS"
Use ADDLOCAL=ALL to install also the development files.
AppVeyor provides only x86 and x64 installers. You can build your own, also for
ARM and ARM64, using misc/build-msi.ps1 which requires
WiX Toolset v3 (at least version 3.14 for ARM64).
From a Visual Studio environment for the target architecture, install FreeTDS using an
absolute CMAKE_INSTALL_PREFIX, copy any additional library
needed, like OpenSSL, to its bin directory, then run
powershell -ExecutionPolicy Bypass -File misc\build-msi.ps1 -SourceDir . -InstallDir C:\freetds-arm64 -Arch arm64 -OutFile freetds.msi
If compiled correctly FreeTDS ODBC driver supports component registration. Although an ODBC driver is not a Windows component you can register the driver with regsvr32 utility or you can use this feature with some installer and register the driver as a standard component.
Once the ODBC driver is registered in the system you can configure it from Control Panel.
FreeTDS builds and passes its test suite on all supported versions of OpenVMS: OpenVMS Alpha (8.4 and later), OpenVMS I64 (8.4 and later) and OpenVMS x86 (9.2 and later). Other prerequisites:
| gunzip |
| vmstar or another tar utility |
| MMK |
| Perl (only to build from a git checkout) |
Decompress and unpack the source archive onto an ODS-5 disk.
Make sure extended parse is enabled in your process (SET PROCESS/PARSE=EXTENDED)
and that the feature logical name DECC$EFS_CHARSET is enabled;
these are not required to run FreeTDS, but are necessary for the build and the test suite.
Set default to the top-level source directory and run the configuration script:
$@[.vms]configure
or, if you are building from a git checkout instead of a release tarball:
$@[.vms]configure_trunk
configure_trunk uses Perl to generate the files included in release tarballs.
Two headers, [.include.freetds]encodings.h and [.include.freetds]charset_lookup.h,
require gperf, which is not available on VMS;
copy them from a release tarball or from a build on another system before running configure_trunk.
Pass --disable-thread-safe to the configuration script to build without thread safety.
The configuration script creates a descrip.mms in the top-level source
directory which you may execute by running MMK (a freeware MMS alternative available from GitHub).
The build also creates stage.com; run it to define foreign commands for the utilities.
$MMK$@stage.com
There is no install target; copy the libraries, include files and utilities where you want them.
Build options are set in the user.mms file in the top-level source directory, one per line, for instance
ODBC = 1 ODBC_MARS = 1
The configuration script creates an empty user.mms if it does not exist, and never overwrites it.
ODBCBuild the ODBC driver. The unixODBC driver manager is assumed.
The logical names ODBC_LIBDIR and ODBC_INCDIR must point to the
driver manager libraries and include files, and LIBODBC and LIBODBCINST
to its shareable images; unixODBC ODBC_SETUP.COM defines all of them except ODBC_INCDIR.
ODBC_MARSEnable MARS support in the ODBC driver.
ODBC_WIDEBuild the ODBC UTF-16 (wide) API as well as the UTF-8 one.
ODBC_WIDETESTBuild the ODBC tests using the UTF-16 API.
MSDBLIBMicrosoft behavior in DB-Library, like --enable-msdblib.
OPENSSL_STATICLink statically against OpenSSL. OpenSSL is used if the logical name OPENSSL is defined.
__DEBUG__Build for the OpenVMS debugger, producing compiler listings and linker maps.
To run the tests, copy PWD.in to PWD and edit it (see the section called “Unit Tests”),
point the logical name FREETDSCONF to the freetds.conf to use, then run MMK check;
MMK recheck runs again only the failed tests.
For the ODBC tests odbc.ini and odbcinst.ini must be configured and world-readable,
as the tests run with minimal privileges.
It's best to define the location of the configuration files with logical names, otherwise FreeTDS may build an unparseable mix of Unix and VMS file name syntax, for example
$DEFINE FREETDSCONF DISK$USER:[TDSDIR]freetds.conf
With the ODBC option the build uses /NAMES=AS_IS, producing mixed-case symbol names
needed by unixODBC; this may cause problems calling the FreeTDS libraries from other languages.
AIX® can induce linker indigestion. libtool doesn't always understand that a .a file
can be a shared library. One solution is to build only static libraries with the --disable-shared
configure option.
Another problem seems to be that the linker isn't asked to pull in all the requisite libraries. Cf. this helpful mailing list message.
It looks like system iconv has some issue on Solaris. Try to use GNU iconv.
For more information looks at this discussion.