FreeTDS Development Group

["Federico Alves" <sales AT minixel.com>]

I am trying to compile version 0.83.dev.20080219 and I get this:

T write.lo -MD -MP -MF .deps/write.Tpo -c write.c -o write.o >/dev/null 2>&1
if /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.
-I../../include  -I../../include -D_FREETDS_LIBRARY_SOURCE -DUNIXODBC
-DHAVE_UNISTD_H -DHAVE_PWD_H -DHAVE_SYS_TYPES_H -DHAVE_LONG_LONG
-DSIZEOF_LONG_INT=4  -D_REENTRANT -D_THREAD_SAFE -DDEBUG=1 -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wno-long-long -pthread -fPIC
-Wdeclaration-after-statement -MT convert.lo -MD -MP -MF ".deps/convert.Tpo"
-c -o convert.lo convert.c; \
then mv -f ".deps/convert.Tpo" ".deps/convert.Plo"; else rm -f
".deps/convert.Tpo"; exit 1; fi
 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include
-D_FREETDS_LIBRARY_SOURCE -DUNIXODBC -DHAVE_UNISTD_H -DHAVE_PWD_H
-DHAVE_SYS_TYPES_H -DHAVE_LONG_LONG -DSIZEOF_LONG_INT=4 -D_REENTRANT
-D_THREAD_SAFE -DDEBUG=1 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wno-long-long -pthread -fPIC -Wdeclaration-after-statement -MT convert.lo
-MD -MP -MF .deps/convert.Tpo -c convert.c  -fPIC -DPIC -o .libs/convert.o
convert.c: In function `tds_willconvert':
convert.c:2904: error: duplicate case value
convert.c:2899: error: previously used here
make[4]: *** [convert.lo] Error 1
make[4]: Leaving directory `/usr/src/freetds-0.83.dev.20080219/src/tds'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/usr/src/freetds-0.83.dev.20080219/src/tds'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/src/freetds-0.83.dev.20080219/src/tds'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/freetds-0.83.dev.20080219/src'
make: *** [all-recursive] Error 1

-----Original Message-----
From: ZIGLIO, Frediano, VF-IT [mailto:Frediano.Ziglio AT vodafone.com] 
Sent: Tuesday, January 29, 2008 10:41 AM
To: Federico Alves
Subject: RE: [freetds] 64 Bit Machine Available

Hi Federico,
  thanks for your support. I'll remind your offer when needed. I think that
problem is quite big and will require a lot of time... just to sum up
- Microsoft documentation is wrong, insufficient and not updated. I wrote
some feedback but I know it will take longer
- Linux have two 64-bit ODBC ABI compatibility even using the same DM
(unixODBC)

Here we tested for some ABI for 64-bit and we currently want to provide a
driver which is compatible with any installed DM but till all vendors will
decide an unified 64-bit ODBC API all ODBC developers will have to take very
care developing ODBC applications.

Regards
  Frediano Ziglio

> -----Original Message-----
> From: freetds-bounces AT lists.ibiblio.org 
> [mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of Federico Alves
> Sent: lunedì 21 gennaio 2008 15.57
> To: freetds AT lists.ibiblio.org
> Subject: [freetds] 64 Bit Machine Available
> 
> Dear Freddy
> I also have a 64 Bit Windows machine available for testing, 
> with SQL 2005
> installed. Please contact me via email if you need the 
> admininstrator login.
> Federico
> 
> -----Original Message-----
> From: freetds-bounces AT lists.ibiblio.org
> [mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of
> freetds-request AT lists.ibiblio.org
> Sent: Monday, January 21, 2008 3:37 AM
> To: freetds AT lists.ibiblio.org
> Subject: FreeTDS Digest, Vol 60, Issue 31
> 
> Send FreeTDS mailing list submissions to
>       freetds AT lists.ibiblio.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>       http://lists.ibiblio.org/mailman/listinfo/freetds
> or, via email, send a message with subject or body 'help' to
>       freetds-request AT lists.ibiblio.org
> 
> You can reach the person managing the list at
>       freetds-owner AT lists.ibiblio.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of FreeTDS digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: FreeTDS Digest, Vol 60, Issue 30 (Federico Alves)
>    2. freetds-0.64 install/configure on Solaris10 all 64-bit env
>       using Sun Compiler - ELF64 error (Alek Fiakhretdinov)
>    3. Re: Ongoing work for released version of FreeTDS        
> version0,
>       64, 0, 6182 (Dann Corbit)
>    4. Optimizing memory allocation when using dynamic SQL
>       (Sebastien FLAESCH)
>    5. Re: FreeTDS Digest, Vol 60, Issue 30 (ZIGLIO, Frediano, VF-IT)
>    6. Re: ODBC on 64 bit linux fix. (ZIGLIO, Frediano, VF-IT)
>    7. Re: ODBC on 64 bit linux fix. (Sebastien FLAESCH)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 18 Jan 2008 16:35:45 -0500
> From: "Federico Alves" <sales AT minixel.com>
> Subject: Re: [freetds] FreeTDS Digest, Vol 60, Issue 30
> To: <freetds AT lists.ibiblio.org>
> Message-ID: <037301c85a1a$161b8150$425283f0$@com>
> Content-Type: text/plain;     charset="us-ascii"
> 
> If somebody needs a 64 Bit machine for testing, Freddy can 
> use the one that
> he knows. He has the IP address and the password. It is a RED 
> HAT 5 with
> license.
> Federico
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 18 Jan 2008 18:26:11 -0500
> From: Alek Fiakhretdinov <alek.fiakhretdinov AT db.com>
> Subject: [freetds] freetds-0.64 install/configure on Solaris10 all
>       64-bit env using Sun Compiler - ELF64 error
> To: freetds AT lists.ibiblio.org
> Message-ID:
>       
> <OFA1C752DA.A206D6CA-ON852573D4.00792B77-852573D4.0080B7D9 AT db.com>
> Content-Type: text/plain; charset="US-ASCII"
> 
> Dear freetds community,
> 
> I am trying to install and configure the latest freetds-0.64  
> kit together 
> with DBD::Sybase driver on Solaris-10 all 64-bit environment.
> Perl itself has been rebuilt with 'use64bitint=define, 
> use64bitall=define' 
> options and successfully works with a few database modules (Sybperl, 
> DBD::Oracle) - all installed using the same CFLAGS as were 
> used during 
> Perl installation.
> 
> I am using SUN compiler and associated build tools (not gcc).
> 
> The problem is that I can't have a loader to use a correct 
> set of 64-bit 
> libraries during the 'make' step of the FreeTDS installation 
> even though 
> per my understanding I am providing all necessary info.
> 
> Will Greatly (!!!) appreciate any help as I was struggling 
> with this for a 
> few days with no luck.
> 
> Here are the details:
> 
> 1.      Perl
> 
> $ perl -V
> Summary of my perl5 (revision 5 version 10 subversion 0) 
> configuration:
>   Platform:
>     osname=solaris, osvers=2.10, archname=sun4-solaris-64
>     uname='sunos nygmwsp011.us.db.com 5.10 generic_118833-33 
> sun4u sparc 
> sunw,sun-blade-100 '
>     config_args='-Dprefix=/usr/perl5/5.10.0 -Duse64bitall 
> -Duse64bitint 
> -de'
>     hint=recommended, useposix=true, d_sigaction=define
>     useithreads=undef, usemultiplicity=undef
>     useperlio=define, d_sfio=undef, uselargefiles=define, 
> usesocks=undef
>     use64bitint=define, use64bitall=define, uselongdouble=undef
>     usemymalloc=n, bincompat5005=undef
>   Compiler:
>     cc='cc', ccflags ='-xarch=generic64 -D_LARGEFILE_SOURCE 
> -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV',
>     optimize='-O',
>     cppflags='-xarch=generic64'
>     ccversion='Sun WorkShop 6 update 1 C 5.2 2000/09/11', 
> gccversion='', 
> gccosandvers=''
>     intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321
>     d_longlong=define, longlongsize=8, d_longdbl=define, 
> longdblsize=16
>     ivtype='long', ivsize=8, nvtype='double', nvsize=8, 
> Off_t='off_t', 
> lseeksize=8
>     alignbytes=8, prototype=define
>   Linker and Libraries:
>     ld='cc', ldflags =' -xarch=generic64 
> -L/db/pub/infra/SUNWspro/6.1p9/SUNWspro/WS6U1/lib/v9 
> -L/usr/lib/sparcv9 
> -L/usr/ccs/lib/sparcv9 '
>     libpth=/db/pub/infra/SUNWspro/6.1p9/SUNWspro/WS6U1/lib/v9 
> /usr/lib/sparcv9 /usr/ccs/lib/sparcv9 /usr/lib /usr/ccs/lib
>     libs=-lsocket -lnsl -ldl -lm -lc
>     perllibs=-lsocket -lnsl -ldl -lm -lc
>     libc=/usr/lib/sparcv9/libc.so, so=so, useshrplib=false, 
> libperl=libperl.a
>     gnulibc_version=''
>   Dynamic Linking:
>     dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
>     cccdlflags='-KPIC', lddlflags=' -G -xarch=generic64 
> -L/db/pub/infra/SUNWspro/6.1p9/SUNWspro/WS6U1/lib/v9 
> -L/usr/lib/sparcv9 
> -L/usr/ccs/lib/sparcv9'
> 
> 
> Characteristics of this binary (from libperl):
>   Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP
>                         PERL_USE_SAFE_PUTENV USE_64_BIT_ALL 
> USE_64_BIT_INT
>                         USE_LARGE_FILES USE_PERLIO
>   Built under solaris
>   Compiled at Jan 11 2008 15:59:18
>   @INC:
>     /usr/perl5/5.10.0/lib/5.10.0/sun4-solaris-64
>     /usr/perl5/5.10.0/lib/5.10.0
>     /usr/perl5/5.10.0/lib/site_perl/5.10.0/sun4-solaris-64
>     /usr/perl5/5.10.0/lib/site_perl/5.10.0
> 
> 
> 2.      Solaris env in my session:
> 
> PATH=/usr/xpg4/bin:/usr/ccs/bin:/db/pub/infra/SUNWspro/6.1p9/S
> UNWspro/bin:/u
> sr/bin:.
> CFLAGS=-xarch=generic64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
> -DPERL_USE_SAFE_PUTENV
> LDFLAGS= -xarch=generic64 
> -L/db/pub/infra/SUNWspro/6.1p9/SUNWspro/WS6U1/lib/v9 
> -L/usr/lib/sparcv9 
> -L/usr/ccs/lib/sparcv9
> LD_LIBRARY_PATH=/usr/ccs/lib/sparcv9:/usr/lib/sparcv9:/db/pub/
> infra/SUNWspro
> /6.1p9/SUNWspro/WS6U1/lib/v9
> 
> 3.      configure 
> 
> ./configure --disable-odbc --disable-libiconv --enable-sybase-compat 
> --prefix=/usr/local/freetds --with-tdsver=7.0
> 
> Configure comes up with a libtool which for some reason 
> generates a C++ - 
> like commands so I have to edit the libtool to change the 
> following line:
> 
> wl="-Wl,"
> 
> to
> 
> wl=""
> 
> In this case 'make' comes up with the follwoing log:
> 
> Which has the following warnings:
> 
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "query.c", line 1464: warning: assignment type mismatch:
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> ld: warning: file ./.libs/libtds_objects.a(mem.o): wrong ELF class: 
> ELFCLASS64
> ld: warning: file 
> ../replacements/.libs/libreplacements.a(iconv.o): wrong 
> ELF class: ELFCLASS64
> ld: warning: Symbol referencing errors
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "ct.c", line 767: warning: statement not reached
> "ct.c", line 3925: warning: statement not reached
> "ct.c", line 4186: warning: argument #1 is incompatible with 
> prototype:
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "blk.c", line 520: warning: statement not reached
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "dblib.c", line 3499: warning: statement not reached
> "dblib.c", line 4124: warning: initializer does not fit or is out of 
> range: 32768
> "dblib.c", line 4770: warning: statement not reached
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "bcp.c", line 1493: warning: statement not reached
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "unittest.c", line 84: warning: assignment type mismatch:
> 
> 5.      Question: what's wrong in my ENV and how can I have 
> the configure 
> tool to generate the right libtool, etc. ?
> 
> 
> Regards,
> =Alek
> 
> 
> ---
> 
> This e-mail may contain confidential and/or privileged 
> information. If you 
> are not the intended recipient (or have received this e-mail 
> in error) 
> please notify the sender immediately and destroy this e-mail. Any 
> unauthorized copying, disclosure or distribution of the 
> material in this 
> e-mail is strictly forbidden.
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Fri, 18 Jan 2008 18:30:19 -0800
> From: "Dann Corbit" <DCorbit AT connx.com>
> Subject: Re: [freetds] Ongoing work for released version of FreeTDS
>       version0,       64, 0, 6182
> To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
> Message-ID:
>       
> <D425483C2C5C9F49B5B7A41F8944154701000BCC AT postal.corporate.connx.com>
> Content-Type: text/plain;     charset="us-ascii"
> 
> [snip]
> I said:
> > > There are no guarantees on the addresses alignments that clients
> want to
> > > bind to.
> > >
> > > Consider:
> > > The client creates a memory buffer with the following properties:
> > > For every field there is a leading character which will 
> be 1 if the
> > > field is null and zero if the field is not null.  Every field will
> also
> > > be stored in the memory buffer using its exact width.  
> Now, suppose
> that
> > > the first field in the result set is a single character.  Then the
> next
> > > field will start at offset 3.  For many CPUs, this will 
> cause a bus
> > > error if the succeeding data is simply assigned to a pointer that
> wants
> > > alignment to a type and the type does not support character
> alignment.
> > >
> > > The reason that we made the changes above is that we 
> *were* getting
> bus
> > > errors in running some of our regression tests on some platforms.
> > >
> > 
> > Mmmm... from msdn (linked from SQLBindCol reference)
> > 
> > http://msdn2.microsoft.com/en-us/library/ms709306(VS.85).aspx
> > 
> > So data should be aligned by program. It's also true that we don't
> live
> > in a perfect world so if you tested that others drivers works in all
> > cases it's worth to write such a workaround. Personally I currently
> > don't have a test environment like this.
> 
> You're quite right.  The specification clearly says that the 
> data should
> be properly aligned.  I guess we just altered our source to 
> placate the
> customers, and added the problem generator to our regression tests.
> 
> I think we will probably just maintain our own version of this file.
> Even though the FreeTDS clearly does the right thing, I think 
> it will be
> cheaper for us than fielding technical support calls.  So I do repent
> and retract in dust and ashes.
> ;-)
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Sat, 19 Jan 2008 12:13:08 +0100
> From: Sebastien FLAESCH <sf AT 4js.com>
> Subject: [freetds] Optimizing memory allocation when using dynamic SQL
> To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
> Message-ID: <4791DB44.7010600 AT 4js.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Dear all,
> 
> Frediano Ziglio wrote:
> > http://msdn2.microsoft.com/en-us/library/ms709306(VS.85).aspx
> 
> Interesting, I knew about alignment issues, but from an 
> optimization point
> of
> view I have always asked myself if doing several malloc() of 
> little pieces
> of
> memory is really an issue...
> 
> We used to have our own mem allocation wrapper to optimize 
> this in our VM
> but
> we have removed it in latest version to just use malloc() as is...
> allocating
> any size of memory...
> 
> I really wonder if C runtime library providers (on any 
> platform) did not yet
> optimize malloc() to allocate large blocks of memory (I mean, if you
> allocate
> 4 bytes, does it really just allocate 4 bytes or does it pick 
> 4b in a memory
> pool
> or whatever and just increment an internal offset)?
> 
> This is a real issue for use, as we have different sort of database
> interfaces
> and need to allocate buffers for dynamic SQL result sets...
> 
> Note also that such kind of memory optimizations is IMHO not 
> significant if
> you compare with database communication... am I wrong?
> 
> Any comment/advice is welcome!
> 
> Thanks a lot.
> 
> ;-)
> Seb
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Mon, 21 Jan 2008 09:20:55 +0100
> From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
> Subject: Re: [freetds] FreeTDS Digest, Vol 60, Issue 30
> To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
> Message-ID:
>       <72EBB5FADDA71343B78E1F09FF471F6E452659 AT OBOMEXO02.omnitel.it>
> Content-Type: text/plain;     charset=US-ASCII
> 
> > 
> > If somebody needs a 64 Bit machine for testing, Freddy can 
> > use the one that
> > he knows. He has the IP address and the password. It is a RED 
> > HAT 5 with
> > license.
> > Federico
> > 
> 
> Thanks Federico, in this case I needed a windows 64 machine 
> to test some
> MS implementations.
> 
> freddy77
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Mon, 21 Jan 2008 09:25:53 +0100
> From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
> Subject: Re: [freetds] ODBC on 64 bit linux fix.
> To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
> Message-ID:
>       <72EBB5FADDA71343B78E1F09FF471F6E45265A AT OBOMEXO02.omnitel.it>
> Content-Type: text/plain;     charset=US-ASCII
> 
> > 
> > We have Windows 64b (with VC++ 8 of course) and Linux 64b 
> > machines here...
> > 
> > Send us a test program and we'll check if you want.
> > 
> > Seb
> > 
> 
> I wrote a small test at
> http://freetds.cvs.sourceforge.net/freetds/freetds/src/odbc/un
> ittests/te
> st64.c?view=log. This source is a unittest for freetds so it require
> common.c and common.h to compile and PWD file to configure.
> 
> It works under win32 and linux x86_64 (I used unixODBC and 
> ubuntu 7.10).
> 
> Yesterday I managed to get win64 cross compile (thanks to mingw-w64
> project!). Can I send you compiled freetds for win64 to test?
> 
> freddy77
> 
> > ZIGLIO, Frediano, VF-IT wrote:
> > >> On Jan 18, 10:22am, sf AT 4js.com (Sebastien FLAESCH) wrote:
> > >> -- Subject: Re: [freetds] ODBC on 64 bit linux fix.
> > >>
> > >> | Thank you Steve,
> > >> | 
> > >> | Here is what we have tested:
> > >> | 
> > >> | CFLAGS="-D BUILD_REAL_64_BIT_MODE" ./configure 
> > >> --prefix=/opt3/dbs/tds/0.83 --with-odbc-nodm=/opt3/dbs/uxo/3.0
> > >> | 
> > >> | But when compiling, we get:
> > >> | 
> > >> | odbc.c:794: conflicting types for `SQLParamOptions'
> > >> | /dbs/64bits/uxo/3.0/include/sqlext.h:1893: previous 
> > >> declaration of `SQLParamOptions'
> > >> | 
> > >> | Am I missing something or is this what Christos tried to fix?
> > >> | 
> > >> | The headers comme from UnixODBC 2.2.12 ...
> > >> | 
> > >> | Cheers,
> > >> | Seb
> > >>
> > >> Yes, this is what I fixed.
> > >>
> > >> christos
> > > 
> > > See 
> http://support.microsoft.com/?scid=kb%3Ben-us%3B298678&x=14&y=7
> > > 
> > > Also from our configure.ac
> > > 
> > >                 # check is SQLParamOptions accept SQLULEN
> > >                 AC_TRY_COMPILE([#if defined(_WIN32) || 
> > defined(WIN32) ||
> > > defined(__MINGW32__)
> > > #include <windows.h>
> > > #endif
> > > #include <sql.h>
> > > #include <sqlext.h>
> > > 
> > > SQLRETURN SQL_API SQLParamOptions(SQLHSTMT       hstmt,
> > >         SQLULEN crow, SQLULEN *pirow) {
> > >         return SQL_SUCCESS;
> > > }], [return 0],
> > >                 AC_DEFINE(TDS_SQLPARAMOPTIONS_SQLLEN, 1, 
> > [Define to 1 if
> > > SQLParamOptions accept SQLULEN as arguments]))
> > >         )
> > > 
> > > but in odbc.c
> > > 
> > > SQLRETURN ODBC_API
> > > SQLParamOptions(SQLHSTMT hstmt, SQLULEN crow, SQLULEN FAR * pirow)
> > > {
> > >         SQLRETURN res;
> > > 
> > > This is a problem in MS specifications... pirow should 
> correspond to
> > > SQL_ATTR_PARAMS_PROCESSED_PTR which is not 64-bit according 
> > which above
> > > link. Also SQL_ATTR_PARAMS_PROCESSED_PTR (see SQLSetStmtAttr
> > > documentation) maps to IPD SQL_DESC_ROWS_PROCESSED_PTR 
> which is not
> > > documented as 64-bit. However SQL_ATTR_ROWS_FETCHED_PTR 
> > which correspond
> > > to IRD SQL_DESC_ROWS_PROCESSED_PTR is documented as 64-bit. So is
> > > SQL_DESC_ROWS_PROCESSED_PTR 32 or 64 bit?? Is it 64-bit 
> > only for IRD??
> > > Does pirow maps really to SQL_ATTR_PARAMS_PROCESSED_PTR 
> > that maps on IPD
> > > SQL_DESC_ROWS_PROCESSED_PTR?
> > > 
> > > Someone have a 64-bit windows machine to execute some 
> > test?? I can pass
> > > some source test in order to test all that stuff... just to 
> > know how MS
> > > implemented its specifications... Is MingW available for 64-bit??
> > > 
> > > freddy77
> > > _______________________________________________
> > > FreeTDS mailing list
> > > FreeTDS AT lists.ibiblio.org
> > > http://lists.ibiblio.org/mailman/listinfo/freetds
> > > 
> > 
> > _______________________________________________
> > FreeTDS mailing list
> > FreeTDS AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/freetds
> > 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Mon, 21 Jan 2008 09:35:49 +0100
> From: Sebastien FLAESCH <sf AT 4js.com>
> Subject: Re: [freetds] ODBC on 64 bit linux fix.
> To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
> Message-ID: <47945965.5090006 AT 4js.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Hello Frediano,
> 
> Yes please send us the binaries, but please give a clear description
> (step by step) to execute the test.
> 
> I known nothing about the regression tests (what is "common.[ch]" or
> the PWD file)?
> 
> Do we have to compile the test?
> 
> Will you provide us only binaries?
> 
> Should we compile the whole HEAD sources on Win64 and run our tests?
> 
> Cheers,
> Seb
> 
> ZIGLIO, Frediano, VF-IT wrote:
> >> We have Windows 64b (with VC++ 8 of course) and Linux 64b 
> >> machines here...
> >>
> >> Send us a test program and we'll check if you want.
> >>
> >> Seb
> >>
> > 
> > I wrote a small test at
> > 
> http://freetds.cvs.sourceforge.net/freetds/freetds/src/odbc/un
> ittests/te
> > st64.c?view=log. This source is a unittest for freetds so it require
> > common.c and common.h to compile and PWD file to configure.
> > 
> > It works under win32 and linux x86_64 (I used unixODBC and 
> ubuntu 7.10).
> > 
> > Yesterday I managed to get win64 cross compile (thanks to mingw-w64
> > project!). Can I send you compiled freetds for win64 to test?
> > 
> > freddy77
> > 
> >> ZIGLIO, Frediano, VF-IT wrote:
> >>>> On Jan 18, 10:22am, sf AT 4js.com (Sebastien FLAESCH) wrote:
> >>>> -- Subject: Re: [freetds] ODBC on 64 bit linux fix.
> >>>>
> >>>> | Thank you Steve,
> >>>> | 
> >>>> | Here is what we have tested:
> >>>> | 
> >>>> | CFLAGS="-D BUILD_REAL_64_BIT_MODE" ./configure 
> >>>> --prefix=/opt3/dbs/tds/0.83 --with-odbc-nodm=/opt3/dbs/uxo/3.0
> >>>> | 
> >>>> | But when compiling, we get:
> >>>> | 
> >>>> | odbc.c:794: conflicting types for `SQLParamOptions'
> >>>> | /dbs/64bits/uxo/3.0/include/sqlext.h:1893: previous 
> >>>> declaration of `SQLParamOptions'
> >>>> | 
> >>>> | Am I missing something or is this what Christos tried to fix?
> >>>> | 
> >>>> | The headers comme from UnixODBC 2.2.12 ...
> >>>> | 
> >>>> | Cheers,
> >>>> | Seb
> >>>>
> >>>> Yes, this is what I fixed.
> >>>>
> >>>> christos
> >>> See 
> http://support.microsoft.com/?scid=kb%3Ben-us%3B298678&x=14&y=7
> >>>
> >>> Also from our configure.ac
> >>>
> >>>                 # check is SQLParamOptions accept SQLULEN
> >>>                 AC_TRY_COMPILE([#if defined(_WIN32) || 
> >> defined(WIN32) ||
> >>> defined(__MINGW32__)
> >>> #include <windows.h>
> >>> #endif
> >>> #include <sql.h>
> >>> #include <sqlext.h>
> >>>
> >>> SQLRETURN SQL_API SQLParamOptions(SQLHSTMT       hstmt,
> >>>         SQLULEN crow, SQLULEN *pirow) {
> >>>         return SQL_SUCCESS;
> >>> }], [return 0],
> >>>                 AC_DEFINE(TDS_SQLPARAMOPTIONS_SQLLEN, 1, 
> >> [Define to 1 if
> >>> SQLParamOptions accept SQLULEN as arguments]))
> >>>         )
> >>>
> >>> but in odbc.c
> >>>
> >>> SQLRETURN ODBC_API
> >>> SQLParamOptions(SQLHSTMT hstmt, SQLULEN crow, SQLULEN FAR * pirow)
> >>> {
> >>>         SQLRETURN res;
> >>>
> >>> This is a problem in MS specifications... pirow should 
> correspond to
> >>> SQL_ATTR_PARAMS_PROCESSED_PTR which is not 64-bit according 
> >> which above
> >>> link. Also SQL_ATTR_PARAMS_PROCESSED_PTR (see SQLSetStmtAttr
> >>> documentation) maps to IPD SQL_DESC_ROWS_PROCESSED_PTR 
> which is not
> >>> documented as 64-bit. However SQL_ATTR_ROWS_FETCHED_PTR 
> >> which correspond
> >>> to IRD SQL_DESC_ROWS_PROCESSED_PTR is documented as 64-bit. So is
> >>> SQL_DESC_ROWS_PROCESSED_PTR 32 or 64 bit?? Is it 64-bit 
> >> only for IRD??
> >>> Does pirow maps really to SQL_ATTR_PARAMS_PROCESSED_PTR 
> >> that maps on IPD
> >>> SQL_DESC_ROWS_PROCESSED_PTR?
> >>>
> >>> Someone have a 64-bit windows machine to execute some 
> >> test?? I can pass
> >>> some source test in order to test all that stuff... just to 
> >> know how MS
> >>> implemented its specifications... Is MingW available for 64-bit??
> >>>
> >>> freddy77
> >>> _______________________________________________
> >>> FreeTDS mailing list
> >>> FreeTDS AT lists.ibiblio.org
> >>> http://lists.ibiblio.org/mailman/listinfo/freetds
> >>>
> >> _______________________________________________
> >> FreeTDS mailing list
> >> FreeTDS AT lists.ibiblio.org
> >> http://lists.ibiblio.org/mailman/listinfo/freetds
> >>
> > _______________________________________________
> > FreeTDS mailing list
> > FreeTDS AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/freetds
> > 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
> 
> 
> End of FreeTDS Digest, Vol 60, Issue 31
> ***************************************
> 
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>