Thanks Jameson. depends22.exe gave the required hint.
Apparently msys2 makes gmp (and everything else) depend on msys-2.0.dll.
Who knows why it does that. I thought the entire point of msys was to
create native, standalone Windows applications.
I can now access the dll's.
I imagine it will be enough for me to simply supply the dll's I need, plus
msys-2.0.dll for download somewhere, unless I can find some magic
invocation which builds msys-2.0.dll into the other dlls I'm building.
Bill.
On 15 September 2015 at 03:58, Jameson Nash <vtjn...@gmail.com> wrote:
> You can use a program called depends22.exe to check whether it has any odd
> dependencies. Then try calling just
> `dlopen("C:\\absolute\\path\\to\\lib.dll")` and see whether that works.
> ccall uses the same underlying dlopen call, so once you get it working for
> one, it should work for both.
>
> On Mon, Sep 14, 2015 at 9:55 PM 'Bill Hart' via julia-users <
> julia-users@googlegroups.com> wrote:
>
>> I tried two different dll's with absolute paths, built with recent
>> MinGW64 and Julia's ccall does not work for either. It still says, "The
>> specified module could not be found".
>>
>> The file type is "gmp-6.0.0/.libs/libgmp-10.dll: PE32+ executable (DLL)
>> (console) x86-64, for MS Windows" and it is just GMP, so it has no external
>> dependencies.
>>
>> I have verified that a simple program will link against the dll and run
>> within msys2/MinGW64. So the dll is certainly built correctly.
>>
>> I realise Julia already supplies its own GMP, I'm just using this as a
>> test case because I know there are no other dependencies. The result is the
>> same with libpari.dll, which Julia does not provide.
>>
>> Needless to say I am using the latest Julia 0.4 release candidate.
>>
>> Bill.
>>
>> On 15 September 2015 at 03:42, Tony Kelman <t...@kelman.net> wrote:
>>
>>> You can refer to the path to a library in ccall via a const variable.
>>> BinDeps helps with setting that variable's value based on the
>>> user-dependent install path, so everything is relocatable. You can get by
>>> without BinDeps if you'd like, it's not without its flaws. Here's an
>>> example from Blosc.jl that barely uses BinDeps, only for the purposes of
>>> download_cmd and unpack_cmd:
>>> https://github.com/stevengj/Blosc.jl/blob/master/deps/build.jl
>>>
>>>
>>> On Monday, September 14, 2015 at 6:36:56 PM UTC-7, Bill Hart wrote:
>>>
>>>>
>>>>
>>>> On 15 September 2015 at 02:54, Tony Kelman <to...@kelman.net> wrote:
>>>>
>>>>> On second thought ECOS.jl is a simpler example:
>>>>> https://github.com/JuliaOpt/ECOS.jl/blob/master/deps/build.jl
>>>>>
>>>>> Or MbedTLS.jl, very similar but with multiple libraries:
>>>>> https://github.com/JuliaWeb/MbedTLS.jl/blob/master/deps/build.jl
>>>>>
>>>>>
>>>>> On Monday, September 14, 2015 at 5:51:33 PM UTC-7, Tony Kelman wrote:
>>>>>>
>>>>>> All Julia needs is dll's.
>>>>>>
>>>>>
>>>> Great, that halves the number of permutations for me to try. Thanks.
>>>>
>>>>
>>>>> Best to refer to them via absolute paths in ccall.
>>>>>>
>>>>>
>>>> Ouch. We have by now thousands of ccalls. Anyway I'll give it a try.
>>>>
>>>>
>>>>> See how SCS.jl handles these for a simple example:
>>>>>> https://github.com/JuliaOpt/SCS.jl/blob/master/deps/build.jl
>>>>>>
>>>>>>
>>>> Thanks.
>>>>
>>>>
>>>>> Requiring Windows users of your package to have an MSYS environment
>>>>>> and MinGW-w64 toolchain installed on their computers is asking for
>>>>>> trouble
>>>>>> and not at all recommended.
>>>>>>
>>>>>
>>>> I agree, and I'd prefer to avoid it. But we still need to build them
>>>> ourselves. And I do have a working MSYS and MinGW toolchain (not without
>>>> great cost to management of course).
>>>>
>>>>
>>>>> I don't see why any library that you could build on Windows with
>>>>>> MinGW-w64 couldn't build in cross-compilation from the opensuse build
>>>>>> service - generally it's a deficiency in that library's build system that
>>>>>> should be fixable. Cross-compilation is something that autotools is very
>>>>>> good at, CMake is decent at if you know what you're doing. Rolling your
>>>>>> own
>>>>>> non-standard build system is asking for trouble, you can see places where
>>>>>> Julia's own makefiles have gone to extra lengths involving XC_HOST to
>>>>>> make
>>>>>> this possible.
>>>>>>
>>>>>
>>>> Pari is not our package so there's nothing we can do about their build
>>>> system.
>>>>
>>>> Many Open Source projects in our area simply aren't invested in Windows
>>>> and have existed long before autotools was a thing.
>>>>
>>>> Very basic autotools builds have been produced for Flint a few times,
>>>> even recently, but unfortunately autotools is way too slow and is not able
>>>> to support a number of the features of our build system that we rely on.
>>>>
>>>> Autotools gives an approximation that is good enough for some simple
>>>> applications of Flint, but not for us.
>>>>
>>>>
>>>>>> If you have a working build setup from a local Windows machine that
>>>>>> can produce dll's, most of what you need to do is upload those dll's
>>>>>> somewhere (bintray works fairly well) then set up the BinDeps scripts to
>>>>>> download and determine the install-time paths.
>>>>>>
>>>>>
>>>> Thanks, I'll look at BinDeps next.
>>>>
>>>> I have dedicated web hosting for the dll's, so that isn't a problem.
>>>> Just getting them running from within Julia will be enough.
>>>>
>>>> Bill.
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> On Monday, September 14, 2015 at 5:23:12 PM UTC-7, Bill Hart wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm currently up to working on building the dependencies for our
>>>>>>> Nemo computer algebra package for Julia:
>>>>>>>
>>>>>>> https://github.com/wbhart/Nemo.jl
>>>>>>>
>>>>>>> We have dependencies on the following C libraries:
>>>>>>>
>>>>>>> libpari (Pari/GP)
>>>>>>> Antic (https://github.com/wbhart/Antic)
>>>>>>> Flint (https://github.com/wbhart/flint2)
>>>>>>> mpfr >= 3.1.2
>>>>>>> gmp >= 5.1
>>>>>>>
>>>>>>> Whatever logic I had already coded up in our build.jl to build these
>>>>>>> on Windows 64 and use them from within Julia no longer works. We always
>>>>>>> knew that there were going to be changes in the way things worked, so
>>>>>>> this
>>>>>>> is not unexpected.
>>>>>>>
>>>>>>> So I thought I would take a look at the OpenSUSE build service. But
>>>>>>> flint, pari and antic are not available on there. (I found the WebRPM
>>>>>>> package for Julia and have been using that.)
>>>>>>>
>>>>>>> It looks like someone has tried to build flint on there, but their
>>>>>>> system doesn't cope with the flint build system (or vice versa if you
>>>>>>> prefer).
>>>>>>>
>>>>>>> Pari only builds on Windows 64 with some coaxing (I have succeeded
>>>>>>> in doing that). It certainly won't build with OpenSUSE.
>>>>>>>
>>>>>>> So this means I have to build these binaries myself perhaps and just
>>>>>>> download them from somewhere on the web, which I'm happy to do.
>>>>>>>
>>>>>>> So I tried building binaries in both msys2 and mingw64. After much
>>>>>>> work I cannot figure out where Julia expects to find the binaries. I've
>>>>>>> tried setting PATH and Libdl.LD_LOAD_PATH appropriately. I've tried
>>>>>>> static
>>>>>>> and dynamic libraries, but under no circumstances can I get Julia to
>>>>>>> find
>>>>>>> the libraries. It just says the "module is not found" when trying to
>>>>>>> ccall
>>>>>>> them.
>>>>>>>
>>>>>>> Moreover, OpenSUSE doesn't provide a "make" package, as far as I can
>>>>>>> see. And make is not available from the GitBash shell in Julia on
>>>>>>> Windows
>>>>>>> 64. So even building the software from within Julia currently seems
>>>>>>> impossible.
>>>>>>>
>>>>>>> I also had problems with the gcc not wanting to build 64 bit
>>>>>>> binaries.
>>>>>>>
>>>>>>> Given that OpenSUSE appears out of the question for us on Windows
>>>>>>> 64. can anyone shed any light on how to get Julia compatible libraries
>>>>>>> built (msys2, mingw64??) and what the current best practice is for
>>>>>>> ccall'ing those binaries (how to set the linker path?).
>>>>>>>
>>>>>>> Note that flint and pari both have custom configure arguments that
>>>>>>> must be set and neither flint nor pari uses autotools, though both
>>>>>>> roughly
>>>>>>> emulate an autotools build with some extra bells and whistles.
>>>>>>>
>>>>>>> Any help would be very much appreciated. We have everything working
>>>>>>> beautifully on Linux, but one of the big selling points for us is that
>>>>>>> the
>>>>>>> entire Julia stack works natively on Windows. This is an especially big
>>>>>>> thing for us given that IJulia also works on Windows (most computer
>>>>>>> algebra
>>>>>>> systems do not work on Windows).
>>>>>>>
>>>>>>> Julia is working beautifully for us and we have 40-50,000 lines of
>>>>>>> Julia code locally for our computer algebra package (Nemo + Hecke). But
>>>>>>> getting it working on Windows just seems to be outside of my current
>>>>>>> skill
>>>>>>> set.
>>>>>>>
>>>>>>> One other minor question: because we currently need to build the
>>>>>>> libraries ourselves, we have to (or would like to) run configure and
>>>>>>> make,
>>>>>>> etc., from the shell in Julia. This means directories have to be
>>>>>>> converted
>>>>>>> from the C:\\abc\\def style to /c/abc/def/ style. Is there a Julia
>>>>>>> function
>>>>>>> for doing this, or a best practice?
>>>>>>>
>>>>>>> Bill.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>
