FreeTDS Development Group

["Andrew H. Wakefield" <a_wake AT earthlink.net>]

Freddy, you may have already partially answered my next question -- I
downloaded the "nightly snapshot" yesterday and tried to cross-compile
for Windows. It failed during the make, using the settings that worked
successfully for freetds-0.82. IIRC, the error had something to do with
types.h inclusion.

But that brings up a question about cross-compiling. I'm not sure I'm
doing it right! Here is how I have successfully cross-compiled
freetds-0.82 for Windows. I'm doing this on Ubuntu 9.10 platform:

// edit the configure script -- for some reason, it will not configure
successfully unless
// I force the cross_compiling flag

sed ‘s,cross_compiling=no,cross_compiling=yes,’ -i configure

// build in a separate subdirectory for msw version

cd build/msw 

// configuration options were adopted from the settings in
mingw-cross-env-2.10; I have tried
// some other variations without success, but I am not sure of the
implications of some of these

../../configure –prefix=/usr/i586-mingw32msvc –host=i586-mingw32msvc
--disable-rpath \
–disable-dependency-tracking –disable-shared –enable-static
--enable-libiconv –with-tdsver=8.0 

make
sudo make install

This produces a tsql.exe that does connect to the SQL server ... if I
specify the host and port!

Note that mingw-cross-env-2.10 also changes out wsock32 for ws2_32 -- I
have tried it both ways, and can't tell that there is any difference??

I could use a primer on the "proper" way to cross compile for windows.

Thanks,

Andy Wakefield
a_wake AT earthlink.net 

On Sun, 2010-01-10 at 14:27 +0100, Frediano Ziglio wrote:

> 2010/1/9 James K. Lowden <jklowden AT freetds.org>:
> > James K. Lowden wrote:
> >> It's not
> >> a complete answer because (among other reasons) the db-lib error handler
> >> won't get the correct error string.
> >
> > Hi Freddy,
> >
> > A question for you on this topic.
> >
> > tdserror() assumes errnum can be converted to a string with strerror(3).
> > On Windows that's not true; for winsock errors strerror(3) returns
> > "Unknown error".  Somehow, we need to pass the Win32 error string
> > (returned from tds_prwsaerror()) to the client libraries.  But how?
> >
> 
> The problem is that in Windows C errors (from errno) and system errors
> (from GetLastError/WSAGetLastError or returned from APIs depending on
> API set!) are not compatible! Errors we detect are from errno and
> sockets. However there is no way to distinguish. In dblib structure we
> have a simply oserr (and also in TDSSOCKET but currently is used only
> for socket error that is systems errors). strerror works for C errors
> but not for sockets. System errors messages can be read using
> FormatMessage API (not that straight but I have example codes).
> Currently I added a macro for sock_strerror so it's easier to
> distinguish between strerror and sock_strerror.
> 
> > The db-lib call stack is:
> >
> > connect(2) (e.g.)
> > tdserror(TDSCONTEXT, TDSSOCKET, msgno, oserr)
> > _dblib_handle_err_message(TDSCONTEXT, TDSSOCKET, TDSMESSAGE)
> > dbperror (DBPROCESS, msgno, oserr)
> >
> > I don't want to change the interface to dbperror() or tdserror() just for
> > Win32.
> >
> > My suggestion: add
> >
> >        char * winsock_errstr
> >
> 
> I don't like this... perhaps would be better to understand if is a
> socket error from tds error code.
> 
> > to TDSSOCKET.  Normally it's NULL.  If libtds detects a win32 socket
> > error, it looks up the const static string with tds_prwsaerror() and
> > stores the pointer in winsock_errstr.  When dbperror() calls the client
> > handler, it examines that pointer.  If not NULL, it passes it to the
> > client handler instead of calling strerror(3).  To avoid confusion,
> > dbperror() sets the pointer to NULL after the handler returns.
> >
> > I think this would work with the other client libraries, too.  What do you
> > think?
> >
> 
> Looking at windows constants I would use a trick and an unique error
> number. C errors in windows are very few (the higher constant is 80
> but is not used by FreeTDS) while socket errors are usually higher
> than 10000. Perhaps we could define a tds_strerror that take this
> constants and output a string. (see
> http://msdn.microsoft.com/en-us/library/t3ayayh1%28VS.80%29.aspx and
> http://msdn.microsoft.com/en-us/library/ms740668%28VS.85%29.aspx).
> 
> Another problem is thread safety. strerror is not thread safe, it
> would be better to use strerror_r if available. Under Windows for C
> errors there is _sys_nerrs and _sys_errlist.
> 
> > BTW, I'm working on updates to the UG for 0.92.
> >
> 
> Good! I saw you committed patch for defncopy and Windows, it was one
> of patches I had on my list (you sent me defncopy.c many time ago but
> got no time to check it). I saw some strange include in defncopy like
> replacements.win32.hacked.h, win32.microsoft directory. Also there is
> a strange types.h inclusion in src/tds/token.c... quite strange,
> tds_get_varint_size should be defined in data.c (which include
> types.h), this breaks my cross Windows compile. Also I got a double
> definition cause you added a strncasecmp in include/replacements.h.
> Perhaps should be placed in defncopy.c (like strcasecmp define?).
> 
> Did you see my initial patch for forbid instance and port
> specification on freetds.conf?? I attach it.
> 
> > Regards,
> >
> > --jkl
> >
> 
> freddy77
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds