Re: Problem connecting to Access Database on Windows Server from 32 bit Linux

Alexander Lehner <[email protected]> Fri, 3 May 2013 18:42:02 +0200 (CEST)
Newsgroups gmane.comp.db.mdb-tools.devel
Message-ID <[email protected]>

On Fri, 3 May 2013, Andrew P Jones wrote:

> [...]
> I have a working installation of mdbtools installed from its package by
> apt on 32 bit Linux mint.
>
> However mdbtools tests for the presence of the database before opening
> it.  The way it tests is unreliable when using a Microsoft Access
> database hosted on a Windows server.
>
> The best information I can find to explain this unreliability is here:
>
> https://bugzilla.samba.org/show_bug.cgi?id=7707
> "Short answer: You need to recompile your test program with
>
>    -D_FILE_OFFSET_BITS=64
>
> What's happening is that glibc uses the stat64() system call to handle
> the stat, even with 32-bit non LFS programs. When it gets back a large
> inode number that doesn't fit in a 32-bit value, it generates EOVERFLOW
> in userspace and returns that to the program."
>
>
> ...And from Wikipedia
> https://en.wikipedia.org/wiki/Stat_%28system_call%29
> "The family of functions was extended to implement large file support.
> Functions named stat64(), lstat64() and fstat64() return attributes in a
> struct stat64 structure, which represents file sizes with a 64-bit type,
> allowing the functions to work on files 2 GiB and larger. When the
> _FILE_OFFSET_BITS macro is defined to 64, these 64-bit functions are
> available under the original names."
>
> I would like to be able to build the application from source so I can
> test if the above is true and if it breaks mdbtools for local files.
>
> Finally, if I run  stat <filename> from a terminal prompt the result
> displays with no apparent error and the inode number has 17 digits.  So
> I know the computer is capable of handling it but mdbtools is not.
>
>> The build failed due to the missing glib installation.
>>
> I thought I had glib installed correctly.  I was wrong.  After
> reinstalling it configure appears to work correctly.
>
> Now make fails...
>
> [...]
> make fails like this:
>
> gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include
> -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -g
> -O2 -DSQL -MT backend.lo -MD -MP -MF .deps/backend.Tpo -c backend.c
> -fPIC -DPIC -o .libs/backend.o
> backend.c:31:20: error: static declaration of 'mdb_backends' follows
> non-static declaration
> ../../include/mdbtools.h:150:20: note: previous declaration of
> 'mdb_backends' was here
> make[2]: *** [backend.lo] Error 1
> make[2]: Leaving directory
> `/home/jonesap/temp/mdbtools/mdbtools-0.6pre1/src/libmdb'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> `/home/jonesap/temp/mdbtools/mdbtools-0.6pre1/src'
> make: *** [all-recursive] Error 1
>
> Could anyone offer any suggestions?
>

What version of libmdb are you using?
What says 'gcc --version'?

I just downloaded mdbtools 0.5 release and 'make' was successful.

It seems that the line numbers compared to your error message do not 
match to the sources I've got.

I understand what the error message says and am wondering how such code 
could become an official release. As far as I understand, such 
construction never will compile.


Alex.


------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2