GDBM files on Intel Macs

[kjdon]

There is a problem with GDBM files on Intel Macs. These are little endian, but perl (5) can't detect this. So the perl code always creates the file with a bdb extension on a mac. GS3 runtime has been changed to always look for bdb on a Mac. GS2 runtime? Does this need changing? Demo collections - we need to add a .txt file for the database into svn. Then on installation, this needs to be converted into a database file - just for Intel Mac? or do this for all types? Note, Shaoqun and Xiaofeng discovered this, not me.

[kjdon]

Currently have three options for the database file - gdbm, sqlite, text. (Do they all work with infodb_type option??).

Make text the default. Or sqlite?

At runtime, the code looks for ldb/bdb and if not there, converts the text file to whatever it needs then uses that.

see also ticket #391 which looks at exported cds.

[ak19]

While the changes made by Dr Bainbridge to fix decompression of the txtgz db file and conversion of this into .ldb database file now work in GS2 when using an Apache webserver and when launching server.exe from the command prompt, it fails when double clicking on server.exe.

[ak19]

Solution for entry of 2008-11-05 13:07:30: When double clicking on server.exe (on Windows), need to have Perl in the path. This is only required for GS2's checked out from SVN and not for GS2 binaries installed using the installer, since the binaries come with Perl in the bin/windows folder which is already added to the path in the C++ code for the server.

[ak19]

• the gdbm-txtgz option tested on Windows, Linux and Mac Leopard. The generated txtgz files are all mutually extractable.

• unable to test on Mac Power PC as there's no binary distribution for it (yet). And that's the only one of the Intel Mac, Windows and Linux that works with bdb database files.

[kjdon]

Now we have a new gdbm that works on any endian type file. So I think the problem has gone away.