|FreeTDS User Guide: A Guide to Installing, Configuring, and Running FreeTDS|
|Prev||Chapter 2. Build FreeTDS||Next|
If you've recently built and installed FreeTDS and noticed steps peculiar to your OS, we'll happily include your comments here.
One thing that can be said, if it's not too obvious: check with your vendor or favorite download site. FreeTDS is routinely rolled up into OS install packages. We know of packages for Debian, Red Hat, FreeBSD, and NetBSD. The installation through the package management systems in these environments may well reduce your work to simply make install.
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.0 release fixes-only Branch-1_00 branch. Every build matrix element generates its artifact.
Ramiro Morales also maintains similar builds of the Branch-0_95 branch at https://github.com/ramiro/freetds/releases.
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:
|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
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:
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
Another problem seems to be that the linker isn't asked to pull in all the requisite libraries. Cf. this helpful mailing list message.
You may find it convenient to make an RPM from the source distribution, in which case you'll be glad to know it is easily done:
$ rpmbuild -ta freetds-0.95.tar.bz2