On 14 September 2014 17:46, Tony Kelman <[email protected]> wrote:
>
> > Unfortunately it doesn't even work on my machine. It seems ok for some
> calls into the dll, but as soon as I try to say print something using a
> function in the MPIR dll it segfaults. I suppose it must be linked against
> subtly different Microsoft dll's than Julia and some kind of conflict
> results.
>
> Or maybe different GCC dll's. Exactly which version of MinGW-w64 are you
> using?
>
I've just updated the msys2 packages with pacman. Recently I updated just
some of the packages and not others, and I thought this might have
introduced some incompatibilities. I noticed that if I build MPIR even with
msys2 and not via Julia, the resulting dll doesn't work any more.
After updating msys2 fully to msys 2.0.1, it still doesn't work. So it
looks to me like some new issues have been introduced by the more recent
msys or something.
Their gas also barfs on one of the assembly files which we now have to
patch. This issue affects GMP too, not just MPIR since we use the same code
for that file.
> Might not be compatible with what was used to build Julia. Or there could
> be some issue due to having gmp and mpir both loaded within the same
> process?
>
Just to reiterate, it was working fine before. I even went back to the
precise configure invocation I used before in my bash history to ensure I
was building MPIR the same way as before, and I checked which alpha version
of MPIR I used.
Admittedly I was using Julia 0.2.1 before, not Julia 0.3, which I have now
upgraded to.
I can try downloading Julia 0.2 for Windows again and see if that fixes the
issue I guess.
> We've seen sort-of-similar issues with blas and lapack and various
> packages, though not so much on Windows.
>
> > The problem must be what libtool is doing on mingw64. Make install
> doesn't even copy the generated dll across to the install directory, so you
> have to do this manually.
>
> Hm, yeah, libtool can be very picky, especially when it comes to dll's. I
> think I've used the "subtle and quick to anger" quote on this list before
> when talking about libtool... I've found configuring
> with lt_cv_deplibs_check_method=pass_all can sometimes help.
>
> > I also can't build flint against the Julia mpir and mpfr since Julia
> doesn't seem to distribute the gmp.h and mpfr.h files, and flint requires
> these when building.
>
> Oh, right, damn. Sorry I forgot about that! That is an issue, maybe we
> should open a separate discussion on that general topic. It has come up
> before that various packages would like to link against the same libraries
> as Julia (in the Blas and Lapack cases we're building with an incompatible
> ABI which makes this actually not a good idea in most cases, but for GMP
> and MPFR I think we're configuring them in the default way), so installing
> the corresponding headers would actually be necessary.
>
> Even though I'm not entirely sure what Nemo or Flint do or whether I would
> personally have a use for them, I have some strange desire to see more
> Julia packages be painless to install cross-platform and want to help here.
>
I can understand that.
> Let me know how the runtime configuration of the text file location goes,
>
It won't happen for a while. I'm afraid I'm currently 14 days behind
schedule at work. I've spent days trying to get this to work on Windows and
have just run out of time to keep working on it. I will have to come back
to it when I catch up with everything else that has been piling up. Perhaps
I can spend some more time on it next weekend.
> then I can mock up what BinDeps would look like. It should simplify your
> deps/build.jl script by automating the standard download, extract,
> configure, make steps. There are also some Julia idioms like
> joinpath("a","b") that would be cleaner than what you're doing now with if
> statements to switch between forward slashes and backslashes, and things
> like
>
> cd(newdir) do
> ...
> end
>
> that work in a nicer way including returning to the old directory even on
> failure.
>
>
> Thanks, I will try to incorporate these suggestions in a later incarnation
of the code.
Bill.
