Could you run the tests/test-init.exe again and see what it does? Does it crash or what happens? Does it produce any output?

(In reply to comment #1)
> Could you run the tests/test-init.exe again and see what it does? Does it crash
> or what happens? Does it produce any output?

I second that problem. Just compiled p11-kit-0.12 from source using mingw+msys (gcc 4.6.2) on Windows XP: ./configure --prefix=/mingw, make, make check. It fails at test-init.exe with a messagebox: 

The exception unknown software exception (0xc0000029) occurred in the application at location 0x7c9502cc.

The last output from test-init.exe is:
p11-kit: p11-kit initialization called recursively
p11-kit: p11-kit initialization called recursively

I looked a bit through the code and it seems that this sequence

for (i = 0; i < num_threads; i++) {
		ret = _p11_thread_create (&threads[i], initialization_thread, tc);
		CuAssertIntEquals (tc, 0, ret);
		CuAssertTrue (tc, threads[i] != 0);
	}

from test_threaded_initialization in test-init.c is generating the error.

Also, any output placed after this loop will be visible in the console AFTER the error appears (the program keeps running a little bit after the error is displayed)

I wanted to test again with version 0.13, but it seems that it won't even compile anymore (i double checked version 0.12 - it compiles and crashes during testing as before)

The error I get from 0.13 when I try to run make:
pin.c: In function 'p11_kit_pin_file_callback':
pin.c:476:12: error: 'EOVERFLOW' undeclared (first use in this function)
pin.c:476:12: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [libp11_kit_la-pin.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


I also tried to cross-compile 0.12 on ubuntu, with mingw32 and the problem persists. During testing (with WINE), i can see the following output to the console:
p11-kit: p11-kit initialization called recursively
p11-kit: p11-kit initialization called recursively
wine: Unhandled exception 0xc0000029 at address 0x7bc3e8a8 (thread 003a), starting debugger...
Can't attach process 0037: error 5
.F

There was 1 failure:
1) test_threaded_initialization: test-init.c:164: assert failed

!!!FAILURES!!!
Runs: 2 Passes: 1 Fails: 1

Created attachment 64293 [details] [review]
Use correct shared library extension on windows

 * The windows shared libraries have the .dll extension
 * This means we also need separate directories for the test module
   configs on win32

https://bugzilla.gnome.org/show_bug.cgi?id=44740

Created attachment 64294 [details] [review]
Use Windows thread ids instead of handles for comparisons

 * It seems that the HANDLE's returned from GetCurrentThread
   are often equal for two threads. GetCurrentThreadID doesn't
   have this problem.
 * Separate our cross platform thread_t and thread_id_t types
   even though on unix they're the same thing.

https://bugzilla.gnome.org/show_bug.cgi?id=44740

Created attachment 64295 [details] [review]
Don't rely on loading order for duplicate modules

 * We had relied on module 'two' loading before 'two-duplicate'
   in the conf tests. However this isn't always the case, and the
   name of the module can end up as 'two-duplicate'

https://bugzilla.gnome.org/show_bug.cgi?id=44740

Created attachment 64296 [details] [review]
Fix warning on windows

https://bugzilla.gnome.org/show_bug.cgi?id=44740

Created attachment 64297 [details] [review]
Initialize mutexes correctly in mock module

https://bugzilla.gnome.org/show_bug.cgi?id=44740

Attached some fixes. This also depends on bug #52158 to keep things simple.

Lucian, do these patches fix the issue for you? If you like, I could make you a git branch, or tarball for testing.

If you have time I'd also appreciate you looking over them to make sure I didn't miss anything obvious.

Created attachment 64368 [details]
Test results after patching

I finally managed to apply the patches (wasn't sure about the branch to which I should apply them).

The good news: everything compiles again
The bad news: there is another test failing (in a more controlled manner)

Details: autogen.sh fails on windows (see attachment), so I ran it on linux and then used only configure on windows. The attachment contains the output captured during compile & test (both on windows and ubuntu, using mingw32).

I did managed to have a look at the changes, but from where I'm standing (the average programmer) I simply can't comment on them.

*** Bug 52500 has been marked as a duplicate of this bug. ***

Okay, I merged the patches.

As far as the test failure, could you comment out this line in conf-test.c and run the tests again? 

      p11_kit_be_quiet ();

And then attach the make check output? There should be more lines of output.

(In reply to comment #12)
> *** Bug 52500 has been marked as a duplicate of this bug. ***

I tried building the latest git source today and the errors are gone.  Thank you!

(In reply to comment #13)
> Okay, I merged the patches.
> 
> As far as the test failure, could you comment out this line in conf-test.c and
> run the tests again? 
> 
>       p11_kit_be_quiet ();
> 
> And then attach the make check output? There should be more lines of output.

Hi Stef,

I just tested the version 0.14 package and everything seems ok on Windows/MinGW GCC 4.7.0: configure, compile and the magic phrase "All 8 tests passed"

I'd say that this one is resolved for me, with the following remarks:

- there is a warning in ../common/compat.c:78:1: function declaration isn't a prototype (I don't really care about it anyway)
- some absolute paths seems to be hardcoded at some point - 4 of the tests will fail if i change the p11-kit folder location after running configure & make (I hope this is the intended functionality)

Let me know if you need more info, or if you want me to generate the make check output for the previous version.

(In reply to comment #15)
> (In reply to comment #13)
> > Okay, I merged the patches.
> > 
> > As far as the test failure, could you comment out this line in conf-test.c and
> > run the tests again? 
> > 
> >       p11_kit_be_quiet ();
> > 
> > And then attach the make check output? There should be more lines of output.
> 
> Hi Stef,
> 
> I just tested the version 0.14 package and everything seems ok on
> Windows/MinGW GCC 4.7.0: configure, compile and the magic phrase "All 8
> tests passed"
> 
> I'd say that this one is resolved for me, with the following remarks:
> 
> - there is a warning in ../common/compat.c:78:1: function declaration isn't
> a prototype (I don't really care about it anyway)

That's a really odd warning, since we're declaring an extern variable. Unless somehow Windows defines __argv as a macro?

> - some absolute paths seems to be hardcoded at some point - 4 of the tests
> will fail if i change the p11-kit folder location after running configure &
> make (I hope this is the intended functionality)

Yes, this is pretty common among autotools based projects.