Re: Cross compilation, warnings and errors

On Sat, Jan 22, 2011 at 05:23:13PM -0500, Ken Collins wrote:
> 
> On Jan 22, 2011, at 2:26 PM, James K. Lowden wrote:
> 
> > If memory serves, LPCBYTE is defined in windows.h.  It's not used by FreeTDS, but is provided in the Microsoft-compatible header file, sqlfront.h for use by applications.  The versions of winscard.h I found on the 'net that define LPCBYTE looked very similar to what's in sqlfront.h, though, so it's hard to see exactly what gcc is complaining about.  
> > 
> > If I were you, I'd look into why the "TiniTDS" project includes winscard.h, which supports smartcards.  FreeTDS certainly doesn't need it. If your aim is cross-compilation, minimizing your include file dependencies will make your job easier.   
> 
> The TinyTDS project does not include winscard.h (directly, or indirectly that I know of). Our header looks something like this. https://github.com/rails-sqlserver/tiny_tds/blob/master/ext/tiny_tds/tiny_tds_ext.h

That may well be so.  Luis's message of 19 January indicated a compilation error on line 39 of sqlfront.h for the preprocessor symbol LPCBYTE which had been previously defined on line 22 of winscard.h.  I'm just suggesting that including winscard.h in the FreeTDS compilation is unnecessary, and that including it is the source of the difficulty.  Many people compile FreeTDS using mingw.  

> #ifndef TINYTDS_EXT
> #define TINYTDS_EXT
> #define MSDBLIB
> 
> #include <ruby.h>
> #include <sqlfront.h>
> #include <sybdb.h>
> #include <syberror.h>

Why?  

I realize this isn't documented in the FreeTDS UG, but if you're going to write a db-lib wrapper, you need to understand what MSDBLIB does and why sqlfront.h and sqldb.h are defined.   

Most important: they're *not* needed for TDS compatibility.  With or without them, FreeTDS can connect to and use any Sybase or Microsoft server.   

Sybase and Microsoft define DB-Library differently.  The *API* is a little different.  For example, the response to INT_EXIT from an error handler is different.  The members of the DBDATEREC structure have different names.  And of course SYBCHAR is SQLCHAR and so on, because compatibility never stands before competition.  

http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.ase_15.0.blocks/html/blocks/blocks180.htm

http://msdn.microsoft.com/en-us/library/aa936970%28SQL.80%29.aspx

Sybase originally defined DB-Library and later licensed it to Microsoft, which first changed it in subtle ways (as above) and then abandoned it.  Sybase's header files are 

	sybfront.h
	sybdb.h
	syberror.h

That's all you need to build a perfectly fine FreeTDS application.  If fact I doubt syberror.h is needed.  

For Windows compatibility, FreeTDS also includes header files named according to Microsoft's conventions:

	sqlfront.h
	sqldb.h

which define all those SQL... manifest constants.  This is helpful to someone porting to FreeTDS code originally written to Microsoft's db-lib.  Indeed, with a small amount of preprocessor magic, it's possible to use FreeTDS as a drop-in replacement for Microsoft's library.  I know a few places where that's been done.  

I hope that's clear.  Header files describe a library to the program using it.  We have two sets of header files because we emulate two vendors descriptions of the DB-Library API.  FreeTDS implements the same protocol regardless of the header files -- or even which of the three libraries -- the program chooses to use.  

While I'm on the topic, I'll mention that LPCBYTE has been royal pain in the tukkus for many years now because it's defined in a variety of Microsoft header files.  Because it's defined unconditionally (as a typedef) in their version of sqlfront.h, the developer must be careful including other files first, a problem made worse by the fact that *some* of windows.h is required.  ( WIN32_LEAN_AND_MEAN was always my bad boy.)  

> Luis, I'm rooting for you too :)

Me too!  Let me caution you, though.  None of the FreeTDS utilities use sqlfront.h, and all of them connect to Microsoft servers.  The header files are written in, um, source code, and everything I've just described can be learned from the sources.  By choosing to use sqlfront.h, you bought yourself headaches that could easily have been avoided.  Luckily for your users, though, you bumped into one early and showed up here!   

Sybase's API definition is cleaner and is still supported by the vendor.  Use it unless you have a good reason not to, and you're FreeTDS experience will be smoother.  

HTH.  

--jkl