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 < [email protected]> 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 <[email protected]> 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 <[email protected]> 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. >>>>>> >>>>>> >>>>>> >>> >
