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. >>> >>> >>>
