I checked that the MPIR dll's produced with the updated msys2 also don't work with Julia 0.2.
I can't think of many other variables here. It has to be msys2 related. I could try not patching the assembly file it barfs on, but have it built from C fallback code. But I know for a fact that file is not being used in the functions I'm calling that cause it to segfault. I can try uninstalling msys2 completely and reinstalling it and mingw64 and see if I get any joy. On Sunday, 14 September 2014 19:05:55 UTC+2, Bill Hart wrote: > > > > 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. >
