Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

[Bill Hart]

I just tried to run the latest (master) version of our Nemo package on Windows 64 using Julia 0.4.6 and after many ambiguity warnings (which are harmless) it bombs out with the message below [1].

What we have tried:

1) Building the old version of Nemo with Julia 0.4.6 : works OK

2) Building the new version of Nemo with Julia 0.4.0 : same failure

3) Building the old version of Nemo with Julia 0.4.0 : works OK

This suggests that we've changed something in the latest version of Nemo that screws up precompilation on Windows 64. But we haven't any idea what it might be. It works just fine under Linux.

Does anyone have any idea what might be going wrong on Windows 64?

Bill.

[1] 

ERROR: Failed to precompile Nemo to C:\Users\User\.julia\lib\v0.4\Nemo.ji

 in error at error.jl:21

[Bill Hart]

Here are some other things I tried:

1) Run Julia as administrator : no change

2) turn off precompilation : still doesn't work, error message below [2]

That's the entire error message. There's no useful diagnostic information to suggest what might have gone wrong at all.

Bill.

[2] ================================[ ERROR: Nemo ]=================================

failed process: Process(`'C:\Users\User\AppData\Local\Julia-0.4.6\bin\julia' --check-bounds=yes --code-coverage=none --color=yes 'C:\Users\User\.julia\v0.4\Nemo\test\runtests.jl'`, ProcessExited(3221225477)) [3221225477]

================================================================================

ERROR: Nemo had test errors

[Daniel Høegh]

You could try to run Julia with the `--inline=no` flag to see if you get more debug information.

[Bill Hart]

I think there is a access violation occurring in one of the dlls we are loading in __init__. However, these are precisely the same dlls we used in the old version of Nemo, so I'm quite puzzled how they are causing an access violation just because we are using a later version of Nemo.

I'll have to check all the julia code we use to load the dlls and see what we changed. I know that we are setting some memory functions now that we didn't use to set, so Julia can do counted_malloc.

This is a real head scratcher, because I can't think of a plausible explanation for the problem. If I remove all the code to set the memory functions except the one to set the GMP memory functions, it complains that it can't find the GMP dll. That's despite the fact that we use this dll without problems in the old version of Nemo.

Bill.

[Bill Hart]

I've narrowed it down to an issue in the following snippet of code which is in __init__ in our package:

   ccall((:__gmp_set_memory_functions, libgmp), Void,

      (Ptr{Void},Ptr{Void},Ptr{Void}),

      cglobal(:jl_gc_counted_malloc),

      cglobal(:jl_gc_counted_realloc_with_old_size),

      cglobal(:jl_gc_counted_free))

Can anyone see what could possibly be wrong with this? It works just fine on Linux, but not Windows 64.

Note, we define libgmp as follows (which I am sure is correct):

const pkgdir = realpath(joinpath(dirname(@__FILE__), ".."))

const libdir = joinpath(pkgdir, "local", "lib")

const libgmp = joinpath(pkgdir, "local", "lib", "libgmp")

Bill.

[Bill Hart]

What's totally bizarre about this, apart from the lack of traceback information, is that this is precisely the same as the code used in Julia itself in gmp.jl.

Bill.

[Bill Hart]

The errors are precisely the same if I invoke Julia with --inline=no.

Bill.

[Bill Hart]

I found the issue. The dll is called libgmp-16.dll. But Julia expects the full name of the dll to be provided, i.e. libgmp-16, not just libgmp. This seems a bit fragile to me.

Bill.

[Tony Kelman]

Fragile how? The -16 is part of the library name.

[Bill Hart]

Well, I thought that when you link against libgmp normally, it doesn't care that the filename is libgmp-16.dll. I thought the linker just took care of it for you, So I was surprised by this behaviour. I might just be confused though.

[Tony Kelman]

You're probably thinking of linux sonames with dots. Windows doesn't have that, the dash in the name is a libtool convention for the best approximation you can get to allowing multiple versions of the library to be installed side by side, and different applications to link to different versions. The linker doesn't know about this convention on Windows, it's usually handled by libtool with associated .la or .dll.a files.