windows shared libraries are supposed to be in bin, not lib, which is why usr32 and usr64 are more helpful than lib32 and lib64. although this is only an issue if you plan on using executables in the download also.
just a thought: you can have both the 32-bit and 64-bit dll's on the path, since windows should just skip over the incompatible one On Fri, Jun 20, 2014 at 3:28 AM, Tony Kelman <[email protected]> wrote: > libgit2: Done. https://github.com/jakebolewski/LibGit2.jl/pull/10 > (failing lots of tests, but it's a start) > > And found a decent BinDeps solution at least for the binaries we package > ourselves. How about using usr/lib32 and usr/lib64? There's already some > code in BinDeps for the Linux distributions that use those names, why not > use it to our advantage on Windows? > https://github.com/JuliaLang/BinDeps.jl/pull/83 > > > On Thursday, June 19, 2014 7:56:21 PM UTC-7, Tony Kelman wrote: >> >> In that case the binaries were packaged by an upstream project, so we >> have no control over what folder the libraries are packaged in. See >> https://github.com/JuliaLang/BinDeps.jl/issues/36 >> It's bad for NLopt too, where upstream happens to be a little closer to >> us https://github.com/JuliaOpt/NLopt.jl/blob/master/deps/build.jl#L28 >> >> But even if the binaries are packaged in usr32 and usr64, I'm having >> trouble satisfying the binary dependency. It would be useful to add >> an unpacked_dir option to Binaries providers, defaulting to "usr" if unset. >> I found part of where to do that, but it isn't working yet. >> >> >> On Thursday, June 19, 2014 7:34:46 PM UTC-7, Jameson wrote: >>> >>> > poorly equipped to handle simultaneous multi-arch binary package >>> installations >>> >>> agreed. I can't follow entirely why the GLPK steps are complicated, but >>> I think it is because the person who packaged the binaries did not separate >>> them into a usr32 and usr64 folder as I am recommending, so that had to be >>> done after downloading. >>> >>> >>> On Thu, Jun 19, 2014 at 10:24 PM, Tony Kelman <[email protected]> wrote: >>> >>>> I will gladly do that, as soon as BinDeps allows me to use the >>>> resulting binaries without this mess: https://github.com/ >>>> juliaopt/GLPK.jl/blob/master/deps/build.jl#L39 >>>> >>>> BinDeps (and the Julia package manager in general) is currently very >>>> poorly equipped to handle simultaneous multi-arch binary package >>>> installations, even when multiple binaries are combined into the same >>>> download. Until there's a solution for that, I'm going to do what's >>>> easiest. >>>> >>>> For libgit, it helps if a Unix version BinDeps is already set up, so I >>>> can have a go with MinGW which is what I'm much more comfortable with. Last >>>> I checked, Visual Studio binaries require users to install runtime >>>> redistributables and such. >>>> >>>> >>>> On Thursday, June 19, 2014 7:09:18 PM UTC-7, Jameson wrote: >>>> >>>>> As a PSA, when building libraries for windows, please version the >>>>> dependencies into usr32 and usr64 based upon the WORD_SIZE variable. It's >>>>> also suggested that you bundle them into the same download, for >>>>> simplicity, >>>>> although that is less necessary. This will help users (and dev testers >>>>> like >>>>> myself) transition smoothly between 32 and 64 bit versions of Julia >>>>> quickly >>>>> and easily. >>>>> >>>>> libgit2 binaries would be very helpful too. note that we will need >>>>> separate versions for XP and newer OSes per their latest release notice ( >>>>> https://github.com/libgit2/libgit2/releases/tag/v0.21.0-rc2) >>>>> >>>>> >>>>> On Thu, Jun 19, 2014 at 9:53 PM, Jake Bolewski <[email protected]> >>>>> wrote: >>>>> >>>>>> Now that you are offering, how about libgit ;-) >>>>>> >>>>>> Jake >>>>>> >>>>> >>>>> >>>
