Changeset 35550 for main


Ignore:
Timestamp:
2021-10-12T10:35:42+13:00 (3 years ago)
Author:
davidb
Message:

On Windows 64-bit using VisualStudio it was found that malloc was not being explicitly externed, leading to the compiling thinking it returned an 'int' not a pointer to a memory location. The cascading affect of this was to result in binaries being produced that crashed when trying to do something as simple as call gdbm_open(). Fix is to explcilty specify #include <malloc.h>, coded in an 'autoconf' friendly way. Currently only the windows/autoconf.h explicitly defines HAVE_MALLOC to 1

Location:
main/trunk/greenstone2/common-src/packages/gdbm/gdbm-1.8.3
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • main/trunk/greenstone2/common-src/packages/gdbm/gdbm-1.8.3/systems.h

    r26772 r35550  
    176176#define STDERR_FILENO 2
    177177#endif
     178
     179/* Added in to assist with Windows 64-bit compilation */
     180/* See not in windows/autoconf.h for more details     */
     181#if HAVE_MALLOC
     182#include <malloc.h>
     183#endif
  • main/trunk/greenstone2/common-src/packages/gdbm/gdbm-1.8.3/windows/autoconf.h

    r18060 r35550  
    9393/* Define to `long' if <sys/types.h> does not define. */
    9494#undef off_t
     95
     96
     97/*
     98   The following below was added to assist with compiling up GDBM for
     99   Greenstone on Windows 64-bit.  Nothing apparently was externing
     100   malloc() resulting in it being seen as a method that returned an
     101   'int'.  On a 64-bit OS 'int' is not a compatible datatype size for
     102   something that is a pointer into memory (what malloc() actually
     103   returned).  On 32-bit Windows we must have been getting away with
     104   this, as int at 4 bytes is the same size as used for pointers.
     105   
     106
     107   Compiling using Visual Studio on 64-bit Windows generated a warning
     108   about the typcast truncating the value, but (being only a warning)
     109   proceeded anyway.  However, this subsequently leads to GDBM compiled
     110   code crashing when invoked by Greenstone (either as compiled up
     111   binaries such as 'db2txt' or through the Greenstone3 runtime JNI
     112   calls.
     113*/
     114
     115/* Define to 1 if you have malloc header files. */
     116#define HAVE_MALLOC 1
Note: See TracChangeset for help on using the changeset viewer.