On Fri, 25 Feb 2011, Jan Dubois wrote:
>
> As I suspected, there is indeed something wrong with the bundled API_test.dll.
Actually, it turns out the issue was with using Cygwin git. :( Because the
*.dll files in the repo have 644 onstead of 755 permissions they won't get
the FILE_EXECUTE permission on NTFS when checked out with Cygwin git, which
means they can't be loaded with LoadLibrary().
A simple `chmod +x *.dll` fixes this problem. Maybe the mode should be
changed in github to prevent someone else falling into the same trap?
> If I compile the DLL myself with VC6, then t/00_API.t starts to pass.
>
> The api-test/Makefile didn't work with VC6 either, but instead of trying to
> fix it I just build the DLL manually (debugging version):
>
> cl /Zi /LD /MD /DAPI_TEST_EXPORTS API_test.cpp /link /def:API_test.def
>
> It still fails test 6 (and 7) of t/01_Struct.t:
Note that this issue doesn't happen with the pre-compiled libraries, only
when I compile them myself. The issue is the alignment of the structures:
api-test/API_test.cpp starts with:
>>>>>>>>>>>>>>>>>>>>>
#pragma pack(1)
#include "stdafx.h"
#include <malloc.h>
#include <stdio.h>
#include "API_test.h"
<<<<<<<<<<<<<<<<<<<<<
and API_test.h doesn't include any #pragma pack() directive itself,
so it also packs the simple_struct tightly:
typedef struct _simple_struct {
int a;
double b;
char * c;
DWORD_PTR d;
} simple_struct, LPsimple_struct;
The t/01_Struct.t script however claims that "auto" alignment is in
effect, which means the "double b" should be aligned at an 8 byte
boundary instead.
This can easily be fixed by adding some
#pragma pack(push, 8)
...
#pragma pack(pop)
around the structure definition. I don't understand though why the
structure isn't tightly packed in the precompiled API_test.dll that
is in the repo (or even in previous releases of the module).
I do get the Callback/t/03_Jim_Shaw.t failures that everyone else is
getting.
So I guess in summary the module is working correctly after all, even
thought it isn't clear why the API_test.dll isn't broken.
However, in 64 bit I still get the t/03_undef.t failure that seems to
be covered by this bug:
https://rt.cpan.org/Public/Bug/Display.html?id=39730
Just like everyone else commenting on that bug so far, I also have no
idea _why_ this is failing. kmx is suggesting that it is a problem
with the test and not the module, but that isn't obvious to me either.
So I'm not sure where this leaves us with the releasability of the current
codebase. I'll look into the 03_undef.t failure a little more, but obviously
don't know how long it is going to take me.
Cheers,
-Jan
