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 sucessful 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 banch and (from time to time) builds from the post-1.4 release fixes-only Branch-1_4 branch. Every build matrix element generates its artifact.
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™ will probably build and run on most versions of OpenVMS Alpha 7.0 and later with DEC/Compaq C 6.0 or later. Other prerequisites:
| gunzip |
| vmstar |
| MMS or MMK |
Decompress and unpack the source archive using gunzip and vmstar. If
you are untarring on an ODS-5 disk, you should use the /ODS2 or -o
option to create universally VMS-friendly filenames; otherwise the build will fail to locate some files.
Set default to the top-level source directory and run the configuration script:
$@[.vms]configure
This creates a descrip.mms in the top-level source
directory which you may execute by simply running MMS (if you have the Module Management System that
is part of DECset) or MMK (a freeware MMS alternative available from www.madgoat.com).
Further information can be found in the vms/README.vms in the source distribution.
The regular distribution compiles on OS X.
On 18 April 2016, a problem was reported causing linker issues.
Undefined symbols for architecture x86_64: "___strlcpy_chk", referenced from: _tdsdbopen in libsybdb_64.a(dblib.o) _db_env_chg in libsybdb_64.a(dblib.o) _dbcolinfo in libsybdb_64.a(dblib.o) _dbtablecolinfo in libsybdb_64.a(dblib.o) _tds_alloc_dynamic in libsybdb_64.a(mem.o) _tds7_get_instance_port in libsybdb_64.a(net.o) _tds_get_locale in libsybdb_64.a(locale.o) ...
This is due to some mismatch on different project releases. To solve these issue set the target release like
CFLAGS="-mmacosx-version-min=10.8" ./configure
makeor
export MACOSX_DEPLOYMENT_TARGET=10.8
./configure
make
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.